Não, os programas que rejeitam esses arquivos geralmente os rejeitam com base no fato de que o arquivo não é buscável (eles precisam acessar o conteúdo em deslocamentos arbitrários ou várias vezes após o retrocesso etc.). Ou eles querem abrir o arquivo várias vezes. Eles também podem querer reescrever (parte de) o arquivo ou truncá-lo.
O nome pipe
(como |
e /dev/stdin
) ou os nomes não fazem diferença em nenhum desses casos.
Na verdade, no Linux, /dev/stdin
quando stdin é pipe (nomeado ou não) se comporta exatamente como um pipe nomeado, o programa não seria capaz de diferenciar esse /dev/stdin
de um pipe nomeado real.
Em outros sistemas, não é exatamente o mesmo, mas, na verdade, abrir /dev/stdin
ou um pipe nomeado fornecerá a você um descritor de arquivo para um pipe, algo que não é possível de nenhuma maneira.
Então, você precisará criar o arquivo temporário. Note que algumas conchas tornam isso mais fácil. Com zsh
, é apenas:
#! /bin/zsh -
"$@" =(cat)
No Linux e com shells que usam arquivos temporários excluídos para documentos aqui (como bash
, zsh
e algumas implementações de ksh
), você pode fazer:
#! /bin/bash -
"$@" /dev/fd/3 3<< EOF
$(cat)
EOF
No entanto, isso pode mangle o conteúdo do arquivo se ele contiver caracteres NUL ou terminar em linhas vazias.
Uma observação sobre o loop while read
desde que você perguntou.
Primeiro read -r
sem um nome de variável não é válido sh
sintaxe. A sintaxe sh
é especificada por POSIX (ISO 9945, também IEEE Std 1003.1), como a sintaxe C
é especificada pela ISO 9899.
Em essa especificação , você notará que read
requer um argumento de nome de variável . O comportamento quando você omitir é não especificado e, na prática, varia com a implementação sh
do intérprete.
bash
é o interpretador do GNU sh
, como gcc
é o compilador C do GNU. Tanto bash
quanto gcc
têm extensões sobre o que esses padrões especificam.
No caso de read
, bash
trata read -r
como se fosse IFS= read -r REPLY
. Na especificação POSIX, IFS= read -r REPLY
lê stdin até que um caractere \n
ou o final da entrada seja atingido e armazena os caracteres lidos na variável $REPLY
e retorna com um status de saída sucesso se um caractere de nova linha foi lido (uma linha completa) ou falha caso contrário (como EOF antes da nova linha) e deixa o comportamento indefinido se os dados lidos contiverem caracteres NUL ou seqüências de bytes que não formam caracteres válidos .
No caso de bash
, ele armazenará os bytes lidos mesmo que não formem caracteres válidos e remova os caracteres NUL.
read -r
é como read -r REPLY
em ksh
ou zsh
e relata um erro em yash
ou ash
baseado em POSIX.
O comportamento de echo
não é especificado, a menos que seus argumentos não contenham caracteres de barra invertida e o primeiro não seja -n
.
Então, para resumir, a menos que você saiba a implementação% (e versão) do sh
com a qual você está lidando, você não pode dizer o que
while read -r; do
echo "$REPLY" >> "$temp_file"
done
fará. No caso de bash
especificamente, ele armazenará stdin no arquivo_temp, contanto que os dados não contenham caracteres NUL, terminem em um caractere de nova linha e nenhuma das linhas corresponda à expressão regular estendida ^-[neE]+$
(e / ou ou dependendo do ambiente ou como bash
foi compilado como sh
do OS / X, não contém caracteres de barra invertida).
Também é muito ineficiente e não é a maneira como você processa texto em shells .
Aqui, você quer:
cat > "$temp_file"
cat
é um comando padrão , que, quando não recebe nenhum argumento, apenas descarta stdin em seu stdout como está .