Ed Morton's questions

Estou usando o bash no cygwin em um laptop Windows. Gostaria de poder alterar a cor de fundo do meu terminal para verde (a cor real é irrelevante) e, para isso, posso usar um destes comandos:

1. tput setb 2; echo
2. printf '\e]11;#00FF00\a'

Para obter mais informações sobre o que isso printfestá fazendo, consulte how-to-set-the-background-color-of-the-linux-console-screen e o uso específico de 11for background está documentado na página 34 de https://invisible- ilha.net/xterm/ctlseqs/ctlseqs.pdf ( Ps = 1 0 → Change VT100 text foreground color to Pt.e Ps = 1 1 → Change VT100 text background color to Pt.)

O printfaltera imediatamente o fundo de todo o terminal enquanto tputapenas define a cor do que é digitado a seguir, daí echocomeçar na próxima linha vazia, mas não me importo muito com isso. O que mais me importa é o seguinte:

Deixa tputuma pequena borda na cor de fundo original (bege claro, definido pela GUI "Opções" que obtenho clicando no canto superior esquerdo do terminal), como pode ser visto nesta imagem (o cinza claro ao redor da esquerda/inferior da imagem é a cor da minha área de trabalho do Windows):

O printfmuda a cor da borda (é um tom de verde mais claro, tputmas isso é irrelevante):

mas isso não altera a área do plano de fundo definida, tputa menos que eu primeiro reinicialize o que meu original tputfez tput init; echoe depois execute printf:

Posso apenas usar o printfpara conseguir o que quero, desde que não use tput setbprimeiro, mas prefiro usar apenastput setb se puder para portabilidade, então - por que está tputdeixando uma pequena borda da cor de fundo existente e existe alguma maneira dizer tputpara definir a cor de fundo de uma forma que não deixe aquela pequena borda?

Eu também gostaria de saber se existe uma maneira de definir tputtodo o plano de fundo do terminal imediatamente, como printfacontece, em vez de após a próxima string digitada, mas isso não é tão importante quanto se livrar dessa borda.

Informações adicionais agora que @MarcusMüller me deu a dica em um comentário de que isso pode ser um minttyproblema -

Vejo esse mesmo comportamento quando uso git basho Windows em uma máquina diferente. Aparentemente, ambos usam minttycomo emulador de terminal. Como tenho que fazer login em muitas máquinas Windows diferentes e usar cygwinor git bash, gostaria de poder resolver esse problema sem precisar alterar o emulador de terminal toda vez que uso uma dessas máquinas (nem tenho certeza se/como eu poderia fazer isso). Na verdade, se fosse necessário mudar o emulador de terminal para resolver o tputproblema, eu simplesmente usaria a printfabordagem.

Encontrei em set-border-width-for-mintty-window-on-cygwin-windows-10 uma maneira de controlar a largura da borda ~/.minttyrcdefinindo a Paddingvariável e se eu atualizá-la para dizer:

Padding=0

então isso resolve o tputproblema acima, mas

1. Isso significaria que eu teria que alterar o .minttyrcem cada máquina em que fizer login e reiniciar o terminal depois, e
2. Quando abro a GUI "Opções" para alterar qualquer coisa no terminal e salvá-lo, ele sobrescreve o .minttyrcarquivo e remove a Paddingconfiguração

então eu ainda gostaria de encontrar uma maneira de simplesmente tputpreencher essa área de "preenchimento" assim como faz com o resto do plano de fundo.

@Vilinkameni também aponta em um comentário que, com o acima exposto tputem um terminal minttyand MSYS2 MINGW64, qualquer troca de cor ANSI SGR por um ls --colorcomando subsequente ou outro que use cores irá efetivamente redefinir a cor novamente. Isso não acontece se eu usar o acima, printfentão posso perguntar sobre isso em uma pergunta subsequente.

Consulte também "Alterar cores" na parte inferior https://code.google.com/archive/p/mintty/wikis/Tips.wiki#Changing_colours para obter mais informações sobre o acima printfe outras coisas relacionadas a mintty. Meu $TERMvalor é xterm.

Dados os 3 scripts a seguir:

1. printf 'a\nb\nc\n' > file && { head -n 1; cat; } < file
2. printf 'a\nb\nc\n' | { head -n 1; cat; }
3. { head -n 1; cat; } < <(printf 'a\nb\nc\n')

Eu esperaria que a saída de cada um fosse:

a
b
c

mas para alguns deles, em alguns sistemas, esse não é o caso. Por exemplo, no cygwin:

$ printf 'a\nb\nc\n' > file && { head -n 1; cat; } < file
a
b
c

$ printf 'a\nb\nc\n' | { head -n 1; cat; }
a

$ { head -n 1; cat; } < <(printf 'a\nb\nc\n')
a

O que está causando a saída diferente desses scripts?

Informações adicionais - aparentemente, isso não é apenas um headproblema:

$ printf 'a\nb\nc\n' | { sed '1q'; cat; }
a
$ printf 'a\nb\nc\n' | { awk '1;{exit}'; cat; }
a

$ { sed '1q'; cat; } < <(printf 'a\nb\nc\n')
a
$ { awk '1;{exit}'; cat; } < <(printf 'a\nb\nc\n')
a

Qual seria uma maneira POSIX robusta no shell (ou seja, sem apenas invocar awk ou similar uma vez para fazer tudo) para ler um certo número de linhas da entrada e deixar o restante para um comando diferente, independentemente de a entrada vir de um canal ou um arquivo?

Esta pergunta foi inspirada por comentários em uma resposta para classificar todo o .csv com base no valor de uma determinada coluna .

Eu estava usando expansão indireta e contando com o resultado sendo uma string nula quando a variável não está definida:

$ $SHELL --version | head -1
GNU bash, version 4.4.23(1)-release (x86_64-unknown-linux-gnu)
$ unset var
$ echo "${!var}"

$

mas em uma nova caixa Linux que falha com invalid indirect expansion:

$ $SHELL --version | head -1
GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
$ unset var
$ echo "${!var}"
-bash: var: invalid indirect expansion
$

Obviamente, posso alterar meu código para funcionar nos dois lugares, mas até agora não consegui descobrir a diferença exata entre os 2 sistemas que está causando a falha em 1, mas não no outro, e quero saber qual é a melhor diferença resolver esse problema e qualquer coisa semelhante que surgir no futuro.

Se for apenas a mudança na versão do bash, não consigo encontrar nenhuma nota de lançamento ou qualquer coisa que indique isso. Se for alguma opção definida em um, também não consigo encontrar (não é, set -upor exemplo). FWIW aqui está a diferença na shoptsaída entre a máquina que está falhando (segunda coluna) e aquela que não está (terceira coluna):

$ awk 'FNR==1{ARGIND++} {a[$1,ARGIND]=$2; b[$1]} END{for (var in b) if (a[var,1] != a[var,2]) print var, a[var,1], a[var,2]}' bad good | column -t
autocd              off
compat32            off
localvar_unset      off
lastpipe            off
localvar_inherit    off
complete_fullquote  on
assoc_expand_once   off
checkwinsize        on   off
globasciiranges     on
compat40            off
compat41            off
compat42            off
inherit_errexit     off
compat43            off
compat44            off
checkjobs           off
expand_aliases      on   off
globstar            off
progcomp_alias      off
dirspell            off
direxpand           off
login_shell         on   off

Alguém sabe exatamente por que vejo a falha em uma caixa Unix, mas não na outra?