intelfx's questions

Estou escrevendo um script wrapper de shell que deve funcionar como um pager (recebendo entrada em stdin e executando saída em um tty).

Este wrapper prepara o ambiente e as linhas de comando e, em seguida, inicia dois processos em um pipeline: o primeiro é um filtro não interativo e o último é o pager real que precisa controlar um tty (ou melhor, gera o próprio pager real) :

#!/bin/bash

...

col -bx | bat "${bat_args[@]}" --paging=always

A árvore de processos resultante é assim:

<parent>
\- wrapper.sh
   |- col -bx (dies)
   \- bat ...
      \- less ...

O col -bxprocesso sai após filtrar a entrada e é colhido pelo shell.

É possível se livrar do processo shell, de modo que ele não permaneça enquanto o pager estiver em execução?

Pensei em uma solução alternativa usando substituição de processo:

exec bat "${bat_args[@]}" --paging=always < <(col -bx)

Porém, o col -bxprocesso não é colhido pelo shell e permanece no estado Z. Existe uma maneira "certa" de escrever esse wrapper?

Uma construção semelhante a IFS= read -r varé frequentemente vista como uma forma "canônica" no Bash de ler uma linha de entrada em uma variável (por exemplo, em unix.SE ).

É bastante claro por que definir um vazio $IFSpode ser benéfico em geral, ou seja, para controlar (evitar) a divisão de palavras. No entanto, estou tendo problemas para entender por que isso é especificamente necessário ao ler uma única variável. O manual do bash diz:

Se houver mais palavras do que nomes, as palavras restantes e seus delimitadores intermediários serão atribuídos ao sobrenome

Então, mesmo sem alterar o IFS, se readfor passada uma única variável, não deveria acabar salvando a linha inteira naquela variável, conforme desejado? Qual é o motivo para definir um vazio $IFSneste caso?

Estou tentando usar o GNU Parallel para executar um comando para cada argumento de entrada, usando esse argumento como o diretório de trabalho do comando (sem anexá-lo à linha de comando).

Basicamente, o que preciso fazer é:

/foo -> "cd /foo; mycmd"
/bar -> "cd /bar; mycmd"
/baz -> "cd /baz; mycmd"

Parallel tem --workdiro que parece fazer o que eu quero em virtude do suporte {}a strings de substituição:

--workdir meudir
--wd meudir

Os trabalhos serão executados no diretório mydir. O padrão é o diretório atual da máquina local e o diretório de login para computadores remotos.
<...>
mydir pode conter strings de substituição do GNU paralelo.

Para evitar que o argumento seja anexado à linha de comando, tentei usar -n0or -N0:

--max-args max-args
-n max-args

Use no máximo argumentos max-args por linha de comando.
<...>
-n 0 significa ler um argumento, mas inserir 0 argumentos na linha de comando.

No entanto, isso não parece funcionar:

$ mkdir -p $HOME/{foo,bar,baz}
$ printf '%s\n' $HOME/{foo,bar,baz} | parallel --workdir '{}' -n0 'pwd'
parallel: Error: Cannot change into non-executable dir : No such file or directory

Observe o espaço antes do :, que não é um erro de digitação no paralelo GNU, mas uma indicação de que o workdir foi avaliado como uma string vazia. Isso se torna evidente se eu acrescentar uma string fixa a {}, caso em que todos os pwds imprimem essa string fixa:

$ printf '%s\n' $HOME/{foo,bar,baz} | parallel --workdir '/{}' -N0 'pwd'       
/
/
/

O que estou fazendo de errado?