Dipende da cosa intendi per dimensione .
size=$(wc -c < "$file")
ti darà il numero di byte che possono essere letti dal file. IOW, è la dimensione del contenuto del file. Tuttavia leggerà il contenuto del file (tranne se il file è un file normale o un link simbolico al file normale nella maggior parte delle wcimplementazioni come ottimizzazione). Ciò potrebbe avere effetti collaterali. Ad esempio, per una pipe denominata, ciò che è stato letto non può più essere letto di nuovo e per cose come /dev/zeroo /dev/randomche sono di dimensioni infinite, ci vorrà del tempo. Ciò significa anche che è necessaria l' readautorizzazione per il file e potrebbe essere aggiornato l' ultimo timestamp di accesso al file.
È standard e portatile, tuttavia si noti che alcune wcimplementazioni possono includere spazi vuoti iniziali in tale output. Un modo per sbarazzarsi di loro è usare:
size=$(($(wc -c < "$file")))
o per evitare un errore su un'espressione aritmetica vuota in dasho yashquando wcnon produce alcun output (come quando il file non può essere aperto):
size=$(($(wc -c < "$file") +0))
ksh93ha wcincorporato (purché tu lo abiliti, puoi anche invocarlo come command /opt/ast/bin/wc) che lo rende il più efficiente per i file regolari in quella shell.
Vari sistemi hanno un comando chiamato statche è un'interfaccia per le stat()o lstat()chiamate di sistema.
Quelle riportano le informazioni trovate nell'inode. Una di queste informazioni è l' st_sizeattributo. Per i file regolari, questa è la dimensione del contenuto (quanti dati possono essere letti da esso in assenza di errori (questo è ciò che la maggior parte delle wc -cimplementazioni utilizza nella loro ottimizzazione)). Per i collegamenti simbolici, questa è la dimensione in byte del percorso target. Per le pipe con nome, a seconda del sistema, è 0 o il numero di byte attualmente nel buffer delle pipe. Lo stesso vale per i dispositivi a blocchi in cui, a seconda del sistema, si ottiene 0 o la dimensione in byte della memoria sottostante.
Non è necessario il permesso di lettura del file per ottenere tali informazioni, solo il permesso di ricerca nella directory a cui è collegato.
Per ordine cronologico, c'è:
IRIXstat (anni '90):
stat -qLs -- "$file"
restituisce l' st_sizeattributo di $file( lstat()) o:
stat -s -- "$file"
lo stesso tranne quando $fileè un collegamento simbolico nel qual caso è st_sizeil file dopo la risoluzione del collegamento simbolico.
zsh statbuiltin (ora noto anche come zstat) nel zsh/statmodulo (caricato con zmodload zsh/stat) (1997):
stat -L +size -- $file # st_size of file
stat +size -- $file # after symlink resolution
o per memorizzare in una variabile:
stat -L -A size +size -- $file
ovviamente, questo è il più efficiente in quella shell.
GNUstat (2001); anche in BusyBox statdal 2005 (copiato da GNU stat):
stat -c %s -- "$file" # st_size of file
stat -Lc %s -- "$file" # after symlink resolution
(notare che il significato di -Lè invertito rispetto a IRIX o zsh stat.
BSDstat (2002):
stat -f %z -- "$file" # st_size of file
stat -Lf %z -- "$file" # after symlink resolution
Oppure puoi usare la funzione stat()/ lstat()di alcuni linguaggi di scripting come perl:
perl -le 'print((lstat shift)[7])' -- "$file"
AIX ha anche un istatcomando che scaricherà tutte le informazioni stat()(no lstat(), quindi non funzionerà sui collegamenti simbolici) e con le quali potresti post-processarle, ad esempio:
LC_ALL=C istat "$file" | awk 'NR == 4 {print $5}'
(grazie @JeffSchaller per l' aiuto nella comprensione dei dettagli ).
In tcsh:
@ size = -Z $file:q
(dimensioni dopo la risoluzione del collegamento simbolico)
Molto prima che GNU introducesse il suo statcomando, lo stesso poteva essere ottenuto con il findcomando GNU con il suo -printfpredicato (già nel 1991):
find -- "$file" -prune -printf '%s\n' # st_size of file
find -L -- "$file" -prune -printf '%s\n' # after symlink resolution
Un problema però è che non funziona se $fileinizia con -o è un findpredicato (come !, (...).
Il comando standard per ottenere le informazioni stat()/ lstat()è ls.
POSIXly, puoi fare:
LC_ALL=C ls -dn -- "$file" | awk '{print $5; exit}'
e aggiungere -Lper lo stesso dopo la risoluzione del collegamento simbolico. Ciò non funziona per i file di dispositivo, sebbene il 5 ° campo sia il numero maggiore del dispositivo anziché la dimensione.
Per i dispositivi a blocchi, i sistemi in cui stat()restituisce 0 per st_size, di solito hanno altre API per segnalare la dimensione del dispositivo a blocchi. Ad esempio, Linux ha BLKGETSIZE64 ioctl(), e la maggior parte delle distribuzioni Linux ora viene fornita con un blockdevcomando che può farne uso:
blockdev --getsize64 -- "$device_file"
Tuttavia, è necessario disporre dell'autorizzazione di lettura per il file del dispositivo. Di solito è possibile ricavare la dimensione con altri mezzi. Ad esempio (ancora su Linux):
lsblk -bdno size -- "$device_file"
Dovrebbe funzionare ad eccezione dei dispositivi vuoti.
Un approccio che funziona per tutti i file ricercabili (quindi include file regolari, la maggior parte dei dispositivi a blocchi e alcuni dispositivi a caratteri) è quello di aprire il file e cercare fino alla fine:
Con zsh(dopo aver caricato il zsh/systemmodulo):
{sysseek -w end 0 && size=$((systell(0)))} < $file
Con ksh93:
< "$file" <#((size=EOF))
o
{ size=$(<#((EOF))); } < "$file"
con perl:
perl -le 'seek STDIN, 0, 2 or die "seek: $!"; print tell STDIN' < "$file"
Per le pipe con nome, abbiamo visto che alcuni sistemi (almeno AIX, Solaris, HP / UX) rendono disponibile la quantità di dati nel buffer delle pipe in stat()'s st_size. Alcuni (come Linux o FreeBSD) no.
Almeno su Linux, puoi usare il FIONREAD ioctl()dopo aver aperto la pipe (in modalità lettura + scrittura per evitare che si blocchi):
fuser -s -- "$fifo_file" &&
perl -le 'require "sys/ioctl.ph";
ioctl(STDIN, &FIONREAD, $n) or die$!;
print unpack "L", $n' <> "$fifo_file"
Tuttavia, nota che mentre non legge il contenuto della pipa, la semplice apertura della pipa denominata qui può comunque avere effetti collaterali. Stiamo usando fuserper verificare innanzitutto che alcuni processi abbiano già aperto il tubo per alleviarlo, ma questo non è infallibile in quanto fuserpotrebbe non essere in grado di controllare tutti i processi.
Ora, finora abbiamo considerato solo la dimensione dei dati primari associati ai file. Ciò non tiene conto delle dimensioni dei metadati e di tutte le infrastrutture di supporto necessarie per archiviare quel file.
Un altro attributo inode restituito da stat()è st_blocks. Questo è il numero di blocchi da 512 byte utilizzati per archiviare i dati del file (e talvolta alcuni dei suoi metadati come gli attributi estesi su filesystem ext4 su Linux). Ciò non include l'inode stesso o le voci nelle directory a cui è collegato il file.
Le dimensioni e l'utilizzo del disco non sono necessariamente strettamente correlati come compressione, scarsità (a volte alcuni metadati), infrastrutture extra come blocchi indiretti in alcuni filesystem hanno un'influenza su quest'ultimo.
Questo è in genere ciò che viene duutilizzato per segnalare l'utilizzo del disco. La maggior parte dei comandi sopra elencati sarà in grado di ottenere tali informazioni.
POSIXLY_CORRECT=1 ls -sd -- "$file" | awk '{print $1; exit}'POSIXLY_CORRECT=1 du -s -- "$file" (non per le directory in cui ciò includerebbe l'utilizzo del disco dei file all'interno).- GNU
find -- "$file" -printf '%b\n'
zstat -L +block -- $file- GNU
stat -c %b -- "$file"
- BSD
stat -f %b -- "$file"
perl -le 'print((lstat shift)[12])' -- "$file"