Há um sinalizador que você pode definir em um descritor de arquivo (sobre open()
: O_CLOEXEC ou mais tarde com fcntl()
: FD_CLOEXEC) se você não quiser que o fd seja transmitido aos comandos executados.
Isso é o que você deve fazer para seus descritores de arquivos internos se for executar comandos.
Em shells, é isso que o ksh93
faz quando você faz exec 3< some-file
, por exemplo. Para outros shells ou fds abertos com { cmd1; cmd2; } 3< file
, você precisará fechar a mão se não quiser que cmd1
ou cmd2
acesse o fd: {cmd1 3<&-; cmd2; } 3< file
. Essa é uma boa prática, mas nem sempre é seguida, já que geralmente não é crítico se você não fizer isso .
Agora, se o recurso é útil. Sim, vários comandos dependem disso.
Alguns comandos usam um descritor de arquivo como argumento que deve ter sido aberto por um chamador. Alguns exemplos que vêm à mente:
-
xterm
com sua opção-S
-
qemu
para várias coisas -
flock
(para bloquear um arquivo no fd do chamador) - o comando
test
também conhecido como[
para sua opção-t
(OK, o utilitáriotest
é construído na maioria das shells parecidas com Bourne atualmente, mas ainda há um comandotest
que pode ser executado). -
dialog
precisa de descritores de arquivo para entrada do usuário, saída e erro para o usuário e entrada e saída para o chamador, para que você possa usar fds extras para isso. -
gpg
ouopenssl
para o qual você pode especificar um descritor de arquivo para comunicar a frase secreta ou outras informações.
Existem vários utilitários helper (por exemplo, a necessidade de executar pode ser executar uma parte de um comando como um usuário ou grupo diferente usando um setuid / setgid executable) que dependem disso.
A substituição do processo depende disso:
Em, diff <(cmd1) <(cmd2)
, 2 descritores de arquivo (para pipes) são passados para diff
e diff os acessa abrindo-os através do especial / dev / fd / n passado como argumento.
Para shells que não têm substituição de processo, você faz o mesmo com coisas como:
cm1 | { cmd2 | diff /dev/fd/3 -; } 3<&0