Verifica se un descrittore di file è valido

Vorrei fare in modo che uno script bash fornisca informazioni aggiuntive ai descrittori di file (FD) maggiori o uguali a 3, quando sono aperti. Per verificare se un FD è aperto, ho escogitato il seguente trucco:

if (printf '' 1>&3) 2>&-; then
  # File descriptor 3 is open
else
  # File descriptor 3 is not open
fi

Questo è sufficiente per le mie esigenze, ma sono curioso di sapere se esiste un modo più idiomatico di testare se un FD è valido. Sono particolarmente interessato al fatto che esista una mappatura della fcntl(1)syscall su un comando shell, che consentirebbe il recupero dei flag FD ( O_WRONLYe O_RDWRper verificare se l'FD è scrivibile O_RDONLYe O_RDWRper verificare se l'FD è leggibile).

In ksh(entrambe le varianti AT&T e pdksh) o zsh, puoi fare:

if print -nu3; then
  echo fd 3 is writeable
fi

Non scriveranno nulla su quel fd, ma controllano comunque se il fd è scrivibile (usando fcntl(3, F_GETFL)) e segnalano un errore altrimenti:

$ ksh -c 'print -nu3' 3< /dev/null
ksh: print: -u: 3: fd not open for writing

(a cui puoi reindirizzare /dev/null).

Con bash, penso che la tua unica opzione sia quella di verificare se un dup()successo ha successo nel tuo approccio, anche se ciò non garantisce che il fd sia scrivibile (o chiama un'utilità esterna ( zsh/ perl...) per fare fcntl()).

Si noti che in bash(come la maggior parte delle shell), se si utilizza al (...)posto di {...;}quello, verrà eseguito un fork di un processo aggiuntivo. Puoi usare:

if { true >&3; } 2<> /dev/null

invece per evitare il fork (tranne nella shell Bourne in cui il reindirizzamento di comandi composti provoca sempre una subshell). Non usare al :posto di truequello che è un builtin speciale , quindi la shell si chiuderebbe quando bash è in modalità di conformità POSIX.

Puoi tuttavia accorciarlo a:

if { >&3; } 2<> /dev/null

Nella descrizione dell'utilizzo dell'applicazione POSIX troverai quanto segue:command

Ci sono alcuni vantaggi nel sopprimere occasionalmente le caratteristiche speciali degli incorporamenti speciali. Per esempio:

command exec > unwritable-file

non provoca l'interruzione di uno script non interattivo, in modo che lo stato dell'output possa essere verificato dallo script.

Ecco perché puoi semplicemente fare:

if    command >&3
then  echo 3 is open >&3
else  ! echo 3 is not open
fi    2<>/dev/null

O...

{ command >&3
  printf %s\\n%.0d  string "0$(($??8:0))" >&"$(($??1:3))"
} 2<>/dev/null

Che scriverà una stringa seguita da una \newline su stdout o 3 e passerà comunque a uno stato di uscita diverso da zero quando 3 non è aperto perché la matematica fatta su $?finisce non riuscendo a convertire l'ottale 08 in % decimale ma non si tronca affatto l'ottale 00 .

O...

command exec >&3 || handle_it

Ma se stai usando ksh93, puoi semplicemente fare:

fds

Per un elenco di descrittori di file aperti. Aggiungi -lper vedere dove vanno.

I descrittori di file aperti sono disponibili in /proc/<pid>/fd. Per elencare, ad esempio, i descrittori di file aperti della shell corrente che puoi emettere ls -l /proc/$$/fdche dovrebbero darti qualcosa del tipo:

total 0
lrwx------ 1 testuser testuser 64 jun  1 09:11 0 -> /dev/pts/3
lrwx------ 1 testuser testuser 64 jun  1 09:11 1 -> /dev/pts/3
lrwx------ 1 testuser testuser 64 jun  1 09:11 2 -> /dev/pts/3
lrwx------ 1 testuser testuser 64 jun  1 09:39 255 -> /dev/pts/3

Quando apri un file usando:

touch /tmp/myfile
exec 7</tmp/myfile

Dovrebbe essere elencato da un nuovo ls -l /proc/$$/fd:

lr-x------ 1 testuser testuser 64 jun  1 09:11 7 -> /tmp/myfile

Se chiudi di nuovo il descrittore di file usando exec 7>&-anche questo non è più elencato /proc/$$/fd.

Il tuo trucco sembra carino; ma per un modo idiomatico mi chiedo perché non hai usato:

if ( exec 1>&3 ) 2>&-

Se sei interessato a una soluzione a basso fork per usarla ripetutamente, suggerirei questa funzione:

checkfd () {
    exec 2> / dev / null
    se exec> & 3; poi
        exec 1> / dev / tty
        echo "fd3 OK"
    altro
        echo "fd3 KO"
    fi
    exec 2> / dev / tty
}

Ed ecco cosa produce con un zsh:

$ checkfd            
fd3 KO
$ checkfd 3> / dev / null
fd3 OK
$

Sembra semplicissimo (vedi commenti):

[ -r /proc/$$/fd/$FD ] && echo "File descriptor $FD is readable"
[ -w /proc/$$/fd/$FD ] && echo "File descriptor $FD is writable"

Come extra ... Il test [-r file] non indica se alcuni dati sono effettivamente in attesa di essere letti (/ dev / null supera questo test (vedi commenti)).

[ -r /proc/$$/fd/4 ] \
  && [ read -t 0.0001 -N 0 <&4 ] \
  && echo "Data is waiting to be read from file descriptor 4"

È richiesto un piccolo numero per l'argomento timeout (read -t) o si possono perdere i dati che richiedono un calcolo. È richiesto il test leggibile ([-r file]) o il comando di lettura bombarda se il file non è leggibile. Questo in realtà non leggerà alcun dato perché il conteggio dei byte è zero (leggi -N 0).

La domanda è piuttosto vecchia, ma comunque: perché non usare i builtin?

for i in {0..5} ; do if [ -t $i ]; then echo "$i is a valid FD"; else echo "$i is INVALID FD"; fi; done

Produzione:

0 is a valid FD
1 is a valid FD
2 is a valid FD
3 is INVALID FD
4 is INVALID FD
5 is INVALID FD

Quindi, per rispondere alla domanda, suggerirei:

if [ -t 3 ]; then
  # File descriptor 3 is open
else
  # File descriptor 3 is not open
fi