Is it possible that a program is already using it
Não. Você vê, o redirecionamento de E / S ocorre antes que um programa ou um script seja iniciado.
Normalmente, quando um programa ou script é iniciado, somente os descritores padrão (0 / entrada padrão, 1 / saída padrão e 2 / erro padrão) são abertos. (Eles podem se referir a um terminal, dispositivo, arquivo ou até mesmo um soquete de rede; mas eles devem estar abertos. Em vez de "fechar" um, redirecionamos um descritor indesejado de / para /dev/null , essencialmente "nowhere" / "nada".)
Os programas usam descritores via syscalls como open , que usam um descritor livre. Ou seja, eles não pedem ao kernel para abrir um arquivo ou socket para um descritor específico , o kernel escolhe o descritor. Assim, o único caso quando um programa usa um descritor adicional, é quando se espera que ele já esteja aberto quando o programa é iniciado. Existem alguns daemons utilitários raros como este - além dos descritores padrão, eles esperam que, se, e. o descritor 3 está aberto quando eles iniciam, ele está conectado ao serviço de gerenciamento (ou algo semelhante).
Se um programa decide usar um descritor hard-coded (e a única razão que o faz, é porque ele bifurca e executa outro programa que espera que o descritor seja aberto; como eu disse, isso é muito raro), o descritor já aberto é fechado quando o programa o substitui com o que ele usa. (A propósito, o kernel faz o fechamento, quando o programa indica que eles querem usar um descritor específico usando, por exemplo, dup2() em sistemas POSIXy; o processo não precisa se importar.)
Os scripts de shell (Bash e sh) usam números de descritores fixos, portanto, é possível que um script use um descritor específico para fazer alguns redirecionamentos de entrada / saída. No entanto, quando isso acontece, os redirecionamentos anteriores são simplesmente ignorados e não têm efeito, porque os scripts assumem que o descritor foi fechado. (Se um descritor estiver aberto e o script usar esse descritor para algum material interno, o descritor original será fechado primeiro - pelo kernel e pelos motivos mencionados no parágrafo anterior - quando os scripts o redirecionarem. Para qualquer tipo de vazamento de dados, o script precisaria especialmente testar se um descritor já estivesse aberto, e evitar redirecionando-o.
Observe também que as unidades ou canais de E / S do Fortran não estão relacionados aos descritores, mesmo que ambos usem um número para identificação. Portanto, mesmo que um programa Fortran use a unidade 10, isso não significa que ele use o descritor 10.
Is it safe to just use a fixed fd number for this?
Sim. POSIX diz que um programa pode ter pelo menos 20 descritores abertos, então qualquer número fixo entre 3 e 19 deve funcionar bem.
O ponto chave é documentá-lo bem, de preferência em um breve comentário no início do script (para scripts) ou no uso ( -h ou --help opção da linha de comando) e man page (para programas ).
Para scripts, você pode assumir que, se surgir um conflito (e, se ocorrer, será do tipo "o script não funciona, pois o canal fecha assim que o programa for iniciado", conforme detalhado acima), os usuários podem alterar o número do descritor fixo para atender melhor às suas necessidades. Então, sua tarefa como roteirista é planejar com antecedência e tornar isso mais fácil para aqueles que vêm depois. (Um comentário claro descrevendo sua intenção e o design geral é suficiente; não é necessário tornar o número do descritor uma variável ou descrever cada pequena ação que o script faz.)
Para programas, é uma boa ideia torná-lo configurável em tempo de execução. Por exemplo, você poderia ter seu programa / daemon usando o descritor 3, se aberto, para o protocolo de controle especial com uma interface gráfica com o usuário; mas, usando alguma opção de linha de comando, como '-c 5', use o descritor nomeado (ou, com -c /dev/name ou -c named-pipe ou -c :socketpath use o arquivo especificado, o named pipe ou o soquete do domínio local). Dessa forma, os usuários podem contornar conflitos com scripts com facilidade.