usando _ em vez de para stdin usando o bash

Question

Qual é a diferença entre usar _< e < para stdin ao usar substituição de processo. Isso é feito usando o bash.

Exemplo:

read bytes _< <(du -bcm random_iso.iso | tail -1); echo $bytes

    

Answer 1

Isso não é um operador _< , que é um argumento _ para passar para a leitura e o operador de redirecionamento < . <(cmd) em si é a subtituição do processo (que se expande para um nome de arquivo que aponta para um pipe).

O que isso faz é executado:

read bytes _  < /proc/self/fd/x

Onde o fd x é o final de leitura de um pipe.

No outro (escrito) final do pipe, um processo de subshell em segundo plano está executando du -bcm random_iso.iso | tail -1 com seu stdout redirecionado para esse pipe.

Portanto, read armazenará na variável $bytes a primeira palavra da última linha da saída de du -bcm e o restante da linha na variável $_ .

Agora eu não sei onde esse du -bcm faz sentido. Nenhuma das opções -b , -c nem -m é padrão. Embora -c seja bastante comum e seja para dar o tamanho cumulativo, com GNU du , -b é obter o tamanho do arquivo (não uso do disco) em bytes, enquanto -m é obter o tamanho arredondado para o próximo mebibyte, então eles seriam opções conflitantes (embora talvez eles usem -b para seu efeito colateral de habilitar --apparent-size ). O FreeBSD du tem -m (para mebibytes), não -b , o Solaris não tem nenhum ...

Parece que foi uma maneira complicada de escrever:

wc -c < random_iso.iso

Ou:

du --apparent-size -cm random_iso.iso | awk 'END{print $1}'

Se eles realmente quisessem que o tamanho do arquivo fosse arredondado para o próximo mebibyte em um sistema GNU.

    

Answer 2

Como mencionado, _< não é um redirecionamento. Isso está passando _ como o argumento final para read . O < é então interpretado como um operador de redirecionamento separado, redirecionando a saída da substituição do processo para stdin.

Tornou-se convencional nos scripts Bash usar _ como uma "variável descartável" em conjunto com o read builtin. No bash, _ é uma variável especial que é definida para o argumento final de um comando após cada comando ser executado. Nesse caso, significa que bytes será atribuído ao primeiro campo e os campos restantes serão descartados na variável _ , em vez de atribuir todos os campos restantes em bytes .

Embora essa seja uma convenção, há várias boas razões para evitar o uso incorreto de _ .

• Esse comportamento de _ não é especificado por POSIX. A maioria das conchas não faz nada de especial com isso.
• Em zsh , _ tem o atributo readonly e usar isso fará com que o shell envie um erro.
• Em mksh , _ tem apenas o comportamento do bash no modo interativo. Em um script não interativo, _ é usado para uma finalidade diferente e não é atribuído a nada após cada comando.
• em ksh93 , _ é definido apenas para o último argumento do último comando em uma linha. Os comandos devem estar fisicamente localizados em linhas de código separadas para poder usar _ . Além disso, _ em ksh93 está sobrecarregado para ter muitos outros usos em vários contextos, portanto, não é recomendado atribuir a _ para essa finalidade e fará coisas diferentes dependendo do contexto.

Eu recomendo colocar um espaço antes de um redirecionamento para tornar as coisas mais claras. Eu coloquei algumas orientações sobre o bom estilo de redirecionamento em este artigo .