Quando si reindirizza un elenco di comandi che contiene un reindirizzamento exec, exec> / dev / null non sembra essere ancora applicato in seguito, come ad esempio con:
{ exec >/dev/null; } >/dev/null; echo "Hi"
Viene stampato "Ciao".
Avevo l'impressione che l' {}
elenco dei comandi non fosse considerato una subshell a meno che non exec >/dev/null
facesse parte di una pipeline, quindi nella mia mente dovrebbe ancora essere applicato all'interno dell'ambiente di shell corrente.
Ora se lo cambi in:
{ exec >/dev/null; } 2>/dev/null; echo "Hi"
non c'è output come previsto; il descrittore di file 1 rimane puntato su / dev / null anche per comandi futuri. Questo è dimostrato dalla riesecuzione:
{ exec >/dev/null; } >/dev/null; echo "Hi"
che non darà alcun risultato.
Ho provato a creare una sceneggiatura ea rimediarla, ma non sono ancora sicuro di cosa stia succedendo qui.
Ad ogni punto di questo script cosa sta succedendo al descrittore di file STDOUT?
EDIT: aggiunta del mio output strace:
read(255, "#!/usr/bin/env bash\n{ exec 1>/de"..., 65) = 65
open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fcntl(1, F_GETFD) = 0
fcntl(1, F_DUPFD, 10) = 10
fcntl(1, F_GETFD) = 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
dup2(3, 1) = 1
close(3) = 0
close(10) = 0
open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fcntl(1, F_GETFD) = 0
fcntl(1, F_DUPFD, 10) = 10
fcntl(1, F_GETFD) = 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
dup2(3, 1) = 1
close(3) = 0
dup2(10, 1) = 1
fcntl(10, F_GETFD) = 0x1 (flags FD_CLOEXEC)
close(10) = 0
fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(1, TCGETS, 0x7ffee027ef90) = -1 ENOTTY (Inappropriate ioctl for device)
write(1, "hi\n", 3) = 3
;
dopo randagio }
, che cambia il significato di > /dev/null
non applicare alla lista composta {}
dopo tutto.
close(10)
. Puoi anche pubblicare l'intero contenuto dello script su cui hai eseguito la strace?