www.MegaLab.it

Esempio: controlliamo i dati di dd

Un modo semplice di controllare che cosa passa "attraverso" un processo di dd è chiamarlo in causa con questa invocazione:

dd if=/dev/urandom of=/dev/null bs=4k

Che, ricordiamo (da questo articolo), è equivalente ad eseguire

cat /dev/urandom | dd bs=4k >/dev/null

cat /dev/urandom è il nostro stdin e /dev/null è ciò che ci aspetta in stdout.

Con dd in esecuzione in background entriamo nella directory dei suoi descrittori:

cd /proc/$(pidof dd)/fd

E, uno alla volta, controlliamoli:

cat 0

Vedrete una sequenza praticamente infinita di caratteri casuali, che è la chiamata di cat per la lettura di /dev/urandom e il reindirizzamento in fd0 di dd. Potete premere Ctrl+C in qualsiasi momento per terminare la lettura della sequenza di caratteri casuali. [5]

cat 1

È /dev/null, che è un particolare file in cui non esiste nulla e viene usato come "buco nero", in cui ciò che viene gettato non può più essere recuperato. Infatti, appena tenterete di analizzare fd1 vedrete solo un nuovo prompt di Bash, segno che /dev/null è qualcosa di vuoto e non contiene... nulla.

Esempio: semplice uso di grep

grep è un programma che filtra un file in entrata (dalla sua stessa invocazione o da stdin, avete capito qual è la differenza tra file in entrata e file in uscita?) secondo dei parametri decisi sulla riga di comando, che la maggior parte delle volte corrispondono ad una semplice stringa. Quindi esaminiamo il suo uso più comune:

grep "stringa" <file>

grep guarda in <file> se esiste la stringa "stringa" e ne visualizza le corrispondenze a video. Ma ormai sappiamo che grep può essere usato anche con stdin, e se abbiamo un file <file> che leggiamo con cat la riga si trasforma così:

cat <file> | grep "stringa"

Che è esattamente equivalente all'invocazione precedente. Ma mettiamo il caso che nel sistema non sia installato zgrep e disponiamo solamente di zcat per leggere un file di testo compresso con gzip. Allora dobbiamo per forza di cose usare questa riga di comando:

zcat <file.gz> | grep "stringa"

E possiamo sapere se ci sono corrispondenze senza estrarre il file (o i file) che sono stati compressi nell'archivio <file.gz>. Ma sappiamo anche che, se stdin di grep è equivalente a /dev/fd/0 di se stesso ed è uguale a stdout di zcat, e grep accetta un file come parametro, possiamo modificare la riga precedente così:

zcat <file.gz> | grep "stringa" /dev/fd/0

Dove il /dev/fd/0 che abbiamo compreso nel comando è lo stdin del processo chiamante, ovvero grep. Si può anche scrivere

zcat <file.gz> | grep "stringa" /dev/stdin

Poiché /dev/stdin è un symlink a /dev/fd/0. Ciò vale per tutti i descrittori. [6]

Riassumendo

/dev/fd/0, /dev/fd/1, /dev/fd/2 e /dev/stdin, /dev/stdout, /dev/stderr rispettivamente sono riferiti tutti al processo che li chiama, e hanno effetto solo se il processo chiamante è oggetto di pipe o redirezione. Le directory in /proc si riferiscono a processi già in esecuzione, e ha senso usarli per controllare lo stato di un demone o di un processo in background.

Generalmente parlando, i file descriptors sono come le connessioni neurali, attraverso cui passano i segnali (o flussi di dati) che hanno come destinazione uno o più neuroni per una successiva elaborazione.