Whimusical's questions

Observei um comportamento estranho no zsh 5.9 no mac. (A seguir está uma simplificação para reproduzir o erro, não tenta fazer sentido). Se eu executar em um terminal

$> function assigner() { OPTIONS=mutated } 
$> function main() { typeset OPTIONS; assigner; echo $OPTIONS }  
$> main

Isso produz:

mutated

Mas se eu alterar sutilmente a função principal para redirecionar a saída da chamada de função interna...

$> function main() { typeset OPTIONS; assigner | cat; echo $OPTIONS }

Então o resultado está em branco

E minha var OPTIONS não está mais preenchida. O que esta acontecendo aqui?

Eu estava brincando com um script que envia texto para um tmux stdin após esta resposta ( https://unix.stackexchange.com/a/773049/189571 por @Kamil Maciorowski) e estava fazendo isso de forma errada

tty=$(tmux new-session -d -s aux -PF "#{pane_tty}")
echo -n foo > $tty && tput cr > $tty && echo bar > $tty
tmux capture-pane -t aux -p -S0 -E3

o que resulta em foo PROMPT %> bar(sequenciado indeterminadamente e PROMPT é impresso)

enquanto o mesmo, mas usando o comando tail -f /dev/nullcomo argumento de tmux new-session, como sugeriu Kamil, dá barcomo resultado, que é o que eu esperava

Gostaria de entender por que sem cauda tudo falha. Aqui não é tail -f /dev/nulluma espécie de sleep infinity? Qual é a diferença em não passar nenhum comando? Quero dizer, se você não passar nada para a nova sessão, o painel será mantido ativo até a sessão de eliminação também

Estou fazendo um script em zsh no mac que usa tmux e depois da incrível resposta https://unix.stackexchange.com/users/22565/st%c3%a9phane-chazelas , descobri que quando uso tmux, ele usa um intérprete diferente daquele da minha máquina host.

Portanto, como estou gerando os mesmos literais para os painéis tty e tmux a partir dos meus comandos tput de script, queria saber se havia alguma incompatibilidade nas sequências de escape ANSI que estou produzindo.

Descobri que $TERM é xterm-256color no meu mac e screen-256color em um painel tmux, por isso emiti

%> infocmp xterm-256color screen-256color

Estou usando código que usa tput clear, civis, sgr0, cnorm, rc, sc, home, cd, cr, el, cub1, cud, cuf. O código está funcionando, a saída é produzida no contexto xterm com tput e é bem renderizada em tty e tmux quando tee'ed.

Mas de acordo com o infocmp, clear, por exemplo, tem sequências de escape diferentes em ambos os termos:

comparing xterm-256color to screen-256color.
        clear: '\E[H\E[2J', '\E[H\E[J'

então como isso pode funcionar?

Como questão secundária, muitos dos meus comandos não aparecem na comparação. Isso significa que eles não são suportados teoricamente ou que são comuns em ambos os termos?

Estou adaptando a resposta de Marcus Müller a uma pergunta que fiz na semana passada - um script que redireciona seu stdout para uma sessão tmux para renderizar sequências de escape ANSI e, em seguida, captura a renderização do painel como a saída real do script. Eu sei que não é nada útil, já que você pode imprimi-lo diretamente no stdout e ter o mesmo resultado, mas é apenas uma demonstração para brincar, para trazer o código para um projeto maior e mais complexo de explicar, onde preciso desse recurso :

#!/bin/zsh

tmpdir="$(mktemp -d)"
fifo="${tmpdir}/fifo"
mkfifo "$fifo"
tmux new-session -d -s aux "while true; do cat ${fifo}; done"

exec 3>&1 1>"$fifo"


echo foo
echo bar
tput home
echo -n b

exec 1>&3 3>&-

tmux capture-pane -t "aux" -p -S0 -E1
tmux kill-session -t aux
rm -rf $tmpdir

quais saídas (e devem):

boo
bar

Estou interessado em simplificar o código. É possível usar algum truque que funcione com o redirecionamento stdin em vez de um fifo que precisa ser mantido? Posso usar uma linha de alguma forma que continue imprimindo tudo e feche a sessão automaticamente quando terminar?

Eu tentei e brinquei com tmux pipe-pane, buffer, send-keys e run-shell e não consegui. Principalmente quando a sessão leva stdin como se você tivesse escrito um comando no console, não como o stdin do script que um comando/script que está rodando

Eu sinto que deve ser simplificável de alguma forma.

Capturei a saída de um script que usa tput para desenhar certas coisas na tela. Quando executo cat myoutput, tudo é bem visto (parece que o terminal o reinterpreta desde o início), mas quando edito ou canalizo essa saída, vejo muitas sequências ansi e todas as coisas anteriores à impressão destrutiva, como tput clear e similares.

Como posso pós-processá-lo para obter apenas a "renderização" final?

Melhor ainda, a origem disso é que atualmente estou testando meu script para que ele imprima tudo em um arquivo, exceto no terminal

comexec > >(tee /dev/tty)

existe uma maneira de dizer ao canal stdout para "renderizar" tudo antes de salvar?

Estou desenvolvendo um script zsh que usa read -k. Se eu executar meu script assim ( echo a | myscript), ele não conseguirá obter entrada. Aparentemente, isso se deve ao fato de que -k usa /dev/tty como stdin invariavelmente, e você deve informar read para usar stdin como em read -u0.

Mas então, se eu mudar para -u0 (o que faz o caso anterior funcionar) e executar meu script sem redirecionar tty, ele quebra o script, ele simplesmente não se comporta como executá-lo sem -u0.

EDIT : Após a depuração, parece que o problema é simplesmente que depois de usar -u0, a opção -k1 não lê um único caractere e para mais. read funciona neste caso sem -k, simplesmente armazenando em buffer todas as entradas e salvando-as assim que um EOL chegar

EDIT2 : Depois de mais depuração, sei que é algo relacionado ao modo bruto que não funciona com -u0. Se eu adicionar stty raw/cooked antes da minha leitura, ele funcionará (exceto que o pressionamento de tecla Enter agora é tratado com \r e não \n), mas quando eu o executo com stdin não-tty, ele quebra.

Existe alguma maneira de tornar os dois modos compatíveis?

Na verdade, eu gostaria de entender por que o script se comporta de maneira diferente, se eu leio com -u0 ou não, fd0 é por padrão o mesmo que /dev/tty

Eu tenho um script que pede entrada dos usuários no terminal, portanto caso o script seja chamado com stdout redirecionado para um arquivo, o usuário não tem contexto no prompt. Então, eu gostaria de duplicar o stdout para ambos os sites.

O script gera um cálculo, portanto ainda faz sentido permitir o redirecionamento stdout.

Mas se stdin for fornecido (tipo de comando sim ou contexto não interativo como um cron), faz sentido que a saída seja perfeitamente permitida para não ser exigida no tty.

Então, eu gostaria de fazer algum tipo de lógica como:

If (test -t 0 && ! test -t 1);
  // Tell stdout to print everything  to tty as well

Isso é possível? Ou é fundamentalmente inapropriado?

Parece que me lembro de algum comando ou envvar que diz isso. Eu gostaria basicamente que algo executado no terminal, por exemplo, fornecesse

echo $STDIN 
/dev/tty
echo $STDOUT
/dev/tty
fdescribe 0 or fdescribe /dev/stdin
/dev/tty
fdescribe 1 or fdescribe /dev/stdout
/dev/tty

mas isso pode ser executado em um script ou subprocesso