> & [FILE_DESCRIPTOR] vs> & operatori di reindirizzamento di file bash
Ho letto del reindirizzamento bash e ho riscontrato questi due articoli a riguardo
il primo :
https://www.brianstorti.com/understanding-shell-script-idiom-redirect
affermando che
Puoi usare & [FILE_DESCRIPTOR] per fare riferimento a un valore descrittore di file;
tuttavia quando lo stavo leggendo contemporaneamente al secondo articolo
il secondo
https://catonmat.net/bash-one-liners-explained-part-three
lo ha affermato
Nota anche che in bash, scrivendo questo:
$ command &>fileÈ esattamente lo stesso di:
$ command >&fileLa prima forma è tuttavia preferita.
come mai >&filecreare fileun descrittore di file
Risposte
In realtà sono due diversi operatori che sono in conflitto tra loro, uno dalla shell Bourne, uno dalla shell C.
cmd >&2
Corto per
cmd 1>&2
L'operatore di Bourne shell che viene eseguito cmdcon il suo stdout (fd 1) connesso alla stessa risorsa (stessa descrizione del file aperto ) di quello su fd 2 ( x>&y(o x<&yche è esattamente lo stesso) reindirizza fd x alla stessa risorsa di fd y ).
cmd >& file
È l' cshoperatore C shell ( ) che viene eseguito cmdcon entrambi i suoi fd 1 e 2 collegati a una nuova descrizione del file aperto ottenuta aprendo filein modalità di sola scrittura. Nella sintassi della shell Bourne, l'equivalente sarebbecmd > file 2>&1
Fanno conflitto. Quale sia effettivamente utilizzato dipende dal fatto che l'obiettivo sia numerico o meno.
Se hai:
cmd >&"$file"
L'operatore della shell Bourne verrà utilizzato se $filecontiene una sequenza di cifre decimali e altrimenti verrà utilizzato l'operatore della shell C!
Ecco perché è meglio evitare l'operatore csh e utilizzare invece la sintassi della shell Bourne ( > file 2>&1).
bash(e zsh) ha anche un &>operatore in alternativa a >&, ma si noti che interrompe la conformità POSIX come cmd &> filedovrebbe essere eseguito cmd &e quindi > filein POSIX sh. Tuttavia non ha il problema di conflitto sopra menzionato.