Pode stdout de saída paralela do GNU antes do programa ter saído?

Question

echo bash -c \''echo "hello, world!";sleep 3;'\' | parallel

Este comando não produz nada até que seja concluído. A página man do Parallel afirma:

GNU parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially.

Eu acho que o diabo está no fraseado: você obtém a mesma saída como se fosse executá-lo normalmente, mas não a saída como se você fosse executá-lo normalmente. Eu procurei por uma opção que faria isso, por exemplo --results /dev/stdout , mas isso não funciona.

Meu caso de uso está exibindo a saída do progresso em tempo real do comando que estou executando. Não se trata de quantas tarefas foram concluídas, que paralelas podem ser exibidas para mim, mas da saída de progresso de cada comando individualmente que eu quero ver.

Eu usaria um loop bash ( for i in $x; do cmd & done; ), mas eu quero ser capaz de interromper todas as tarefas com um único Ctrl + C, o que o paralelo me permite fazer.

É possível fazer isso em paralelo? Se não, existe outra ferramenta?

    

Answer 1

Acho que você está procurando por --ungroup . A página man diz:

--group  Group output. Output from each jobs is grouped 
         together and is only printed when the command is finished. 

         --group is the default. Can be reversed with -u.

-u , claro, é sinônimo de --ungroup .

    

Answer 2

Para observar o progresso de alguns trabalhos paralelos, tente --tmuxpane --fg :

parallel --tmuxpane --fg seq {} 10000000 ::: {1..100}

Você também pode estar procurando -u ou (mais provavelmente) --lb . De man parallel :

   --line-buffer
   --lb
       Buffer output on line basis. --group will keep the output together
       for a whole job. --ungroup allows output to mixup with half a line
       coming from one job and half a line coming from another job.
       --line-buffer fits between these two: GNU parallel will print a full
       line, but will allow for mixing lines of different jobs.

       --line-buffer takes more CPU power than both --group and --ungroup,
       but can be much faster than --group if the CPU is not the limiting
       factor.

       Normally --line-buffer does not buffer on disk, and can thus process
       an infinite amount of data, but it will buffer on disk when combined
       with: --keep-order, --results, --compress, and --files. This will
       make it as slow as --group and will limit output to the available
       disk space.

       With --keep-order --line-buffer will output lines from the first job
       while it is running, then lines from the second job while that is
       running. It will buffer full lines, but jobs will not mix. Compare:

         parallel -j0 'echo {};sleep {};echo {}' ::: 1 3 2 4
         parallel -j0 --lb 'echo {};sleep {};echo {}' ::: 1 3 2 4
         parallel -j0 -k --lb 'echo {};sleep {};echo {}' ::: 1 3 2 4

       See also: --group --ungroup

[...]

   --ungroup
   -u  Ungroup output.  Output is printed as soon as possible and by passes
       GNU parallel internal processing. This may cause output from
       different commands to be mixed thus should only be used if you do not
       care about the output. Compare these:

         seq 4 | parallel -j0 \
           'sleep {};echo -n start{};sleep {};echo {}end'
         seq 4 | parallel -u -j0 \
           'sleep {};echo -n start{};sleep {};echo {}end'

       It also disables --tag. GNU parallel outputs faster with -u. Compare
       the speeds of these:

         parallel seq ::: 300000000 >/dev/null
         parallel -u seq ::: 300000000 >/dev/null
         parallel --line-buffer seq ::: 300000000 >/dev/null

       Can be reversed with --group.

       See also: --line-buffer --group

Um exemplo em que -u shines é onde stdout e stderr são misturados na mesma linha:

echo -n 'This is stdout (';echo -n stderr >&2 ; echo ')'

Isso será formatado incorretamente com --lb e --group .

Mas mesmo -u não garante que será formatado corretamente devido à mistura de meia linha entre os processos: link