Início / unix / Perguntas / 523448
Accepted
Yves
Asked: 2019-06-07 18:50:39 +0800 CST

por que é `test.sh & | test.sh` errado

  • 772

Eu tenho um script bash chamado test.shcomo abaixo:

#!/bin/bash

while :
do
    echo xxx
    sleep 1
done

Não sei porque ./test.sh & | ./test.shme dá um erro: -bash: syntax error near unexpected token |', considerando que ./test.sh | ./test.she ./test.sh | ./test.sh &funciona.

bash pipe

1 respostas

  1. Best Answer

    Isso simplesmente não é permitido pela gramática do shell :

    %start  complete_command
%%
complete_command : list separator
                 | list
                 ;
list             : list separator_op and_or
                 |                   and_or
                 ;
...

pipe_sequence    :                             command
                 | pipe_sequence '|' linebreak command
                 ;
...
separator_op     : '&'
                 | ';'
                 ;

    Observe como &ou ;só pode encerrar listas, e listas são apenas parte de um complete_command, que não pode fazer parte de outras produções.

    Isso é apenas uma peculiaridade gramatical; assim como { foo & }é semanticamente semelhante a foo &(as chaves, ao contrário dos parênteses, são usadas apenas para agrupar comandos, elas não criam por si um subshell ou qualquer tipo de escopo), você pode considerar { foo & } | barser semanticamente semelhante a foo & | bar, se este último fosse permitido pela gramática.

    Portanto, a solução alternativa para o seu exemplo é apenas:

    { ./test.sh & } | ./test.sh

    Se você executar isso a partir de um shell interativo, observe que não& criará um job em segundo plano , mas apenas executará o comando de forma assíncrona, porque o lado direito de um pipeline sempre é executado em um subshell e os comandos de um subshell são executados com job controle desabilitado.

    Isso é semelhante a:

    (sleep 3600 &)

    As listas assíncronas (comandos terminados por &) em um subshell são executadas com seu stdin redirecionado /dev/nulle seus sinais SIGINTe SIGQUITignorados. Eles continuarão sendo executados em segundo plano, mas você não poderá trazê-los para o primeiro plano com fg, disownthem, etc, como você pode fazer com trabalhos normais. Além disso, você não será notificado quando eles forem interrompidos ou encerrados.

    Em um script, isso não faz absolutamente nenhuma diferença, pois os scripts são executados com o controle de trabalho desabilitado.

    Mas se você quiser canalizar a saída de um trabalho em segundo plano para um trabalho em primeiro plano em um shell interativo , a única solução portátil que consigo pensar é usar um canal nomeado.

    $ mkfifo fifo
$ command | filter1 > fifo &  # this is the background job
$ < fifo sed 10q | filter2    # this is the foreground job
    • 2

relate perguntas