user001's questions

O efeito do tipo de letra em negrito (ANSI: CSI 1 m) parece depender do emulador de terminal. Por exemplo, executando o seguinte script em diferentes emuladores de terminal

#!/bin/sh
echo "TERM = $TERM"
for mode in 0 2 1 '1;2'; do
    printf '\033[%s;38;5;%dm\033[48;5;%dm%s\033[0m\n' "$mode" 0 15 "testing ($mode)"
done

dá a seguinte saída

Dos emuladores de terminal testados, apenas xtermrenderiza corretamente o texto em negrito (modo=1). Os outros emuladores de terminal parecem selecionar uma cor mais brilhante para o tipo de letra em negrito (geralmente também combinando isso com um tipo de letra em negrito). Estranhamente, stproduz texto em negrito devidamente colorido quando recebe os parâmetros 1;2, correspondentes a bold;faint.

Pensando que talvez esses emuladores de terminal esperem diferentes sequências de controle para fonte em negrito, verifiquei terminfo, mas encontrei unanimidade

$ for term in xterm-256color st-256color rxvt-unicode-256color tmux-256color; do printf "%-24s" "$term"; TERM=$term tput bold | cat -v; echo; done
xterm-256color          ^[[1m
st-256color             ^[[1m
rxvt-unicode-256color   ^[[1m
tmux-256color           ^[[1m

Isso leva à pergunta: quais parâmetros do emulador de terminal controlam o efeito do tipo de letra em negrito? Como evitar a mudança para cores mais brilhantes? Isso pode ser corrigido através Xresourcesou terminfopersonalização? (Como um aparte, existem parâmetros correspondentes para vim? Ele mostra um comportamento semelhante, que não corresponde necessariamente ao do emulador de terminal em que é executado.)

Desde que as barras invertidas do terminal não estejam presentes, as novas linhas de um heredoc são preservadas após capturar a saída de um heredoc em uma variável:

var=$(cat <<-EOF
a
b
c
EOF
)
echo "$var"

a
b
c

No entanto, as novas linhas são perdidas ao tentar armazenar novas linhas de barra invertida:

var=$(cat <<-EOF
a \\
b \\
c
EOF
)

echo "$var"
a \b \c

Adicionar barras invertidas adicionais para escape adicional não ajuda.

Claro, quando não executado em um subshell, um heredoc pode ser usado para gerar linhas que terminam em backslash-newline:

$ cat <<-EOF
a \\
b \\
c
EOF
a \
b \
c

Para contornar esse problema, pode-se adicionar um delimitador de nova linha para gerar a saída desejada por uma transformação da variável:

var=$(cat <<-EOF
a \\@
b \\@
c
EOF
)

tr -d '@' <<<"$var"

a \
b \
c

Existe uma maneira mais direta de preservar as novas linhas de barra invertida de heredocs executados em subshells?

Descobri que definir a extglobopção shell apenas dentro de um composto composto resulta em falha de globs estendidos subsequentes. As opções do shell precisam ser definidas fora dos comandos compostos? Não vi uma indicação de tal requisito nas páginas de manual do Bash.

Como exemplo, o script a seguir funciona bem (imprime a.0 a.1):

#!/bin/bash
touch a.0   a.1 \
      a.b.0 a.b.1
shopt -s extglob
ls "a."!(b*)

No entanto, se as duas últimas linhas forem executadas como um comando composto, o script falhará com o seguinte erro:

syntax error near unexpected token `('
`    ls "a."!(b*)'

Isso foi testado usando as versões Bash de 4.2 a 4.4 e com uma variedade de comandos compostos :

(1) condicional --if

#!/bin/bash
touch a.0   a.1 \
      a.b.0 a.b.1
if true; then
    shopt -s extglob
    ls "a."!(b*)
fi

(2) chaves --{ }

#!/bin/bash
touch a.0   a.1 \
      a.b.0 a.b.1
{
    shopt -s extglob
    ls "a."!(b*)
}

(3) subcamada -- ( ):

#!/bin/bash
touch a.0   a.1 \
      a.b.0 a.b.1
(
    shopt -s extglob
    ls "a."!(b*)
)

Em todos os casos, se shoptfor movido para fora do comando composto, o script será bem-sucedido.

Eu habilitei xterm-keysno tmux para ter ligações de teclas xterm normais, como movimento de palavra inteira, usando as teclas de seta Ctrl .

No entanto, ao habilitá xterm-keys-lo, causa Shift-Enterefeitos indesejados no vim. Em particular, pressionar Shift-Enterno modo normal alterna a capitalização de 13 letras a partir da posição do cursor, independentemente dos limites das palavras. Pressionar as teclas no modo de comando sai desse modo e, em seguida, alterna a capitalização de 13 letras. Normalmente em vim, os resultados deste pressionamento de tecla são mover uma linha para baixo (modo normal) ou executar qualquer comando inserido (modo de comando) e, até onde sei, esses são os comportamentos padrão.

Reproduzi esse efeito com arquivos vazios .tmux.confe .vimrc, portanto, não é um efeito colateral de outras configurações.

Estou tentando entender o que acontece quando um arquivo, que foi mapeado na memória pela mmapchamada do sistema, é posteriormente gravado por outros processos.

Eu tenho mmaped memória com PROT_READproteção no "processo A". Se eu fechar o descritor de arquivo subjacente no processo A e outro processo gravar posteriormente nesse arquivo (não usando mmap; apenas um simples redirecionamento de stdout para o arquivo usando >no shell), a mmapmemória ed no espaço de endereço do processo A será afetada ? Dado que as páginas são somente leitura, eu esperaria que elas não mudassem. No entanto, o processo A está sendo finalizado por SIGBUSsinais como resultado de acessos inválidos à memória ( Non-existent physical address at address 0x[...]) ao tentar analisar a memória mapeada. Estou suspeitando que isso seja decorrente de gravações no arquivo de apoio por outros processos. A configuração MAP_PRIVATEseria suficiente para proteger completamente essa memória de outros processos?

Estou tentando construir um -nameprimário composto para o findcomando a partir de um número arbitrário de strings em uma matriz, no formato \( -name ${a[0]} -or -name ${a[1]} -or -name ${a[2]} ... \). Embora a digitação explícita do nome principal no terminal funcione, armazená-lo em uma variável e recuperá-lo por expansão de parâmetro não funciona. Como a expansão ocorrerá antes finddas execuções, presumo que o problema tenha algo a ver com a citação da variável expandida.

Abaixo está um exemplo mínimo para n=2 nomes, digitados literalmente ou recuperados de uma variável. Embora eu perceba que eu poderia canalizar para grep, eu preferiria fazer tudo com findneste caso.

$ ls
a1  a2  b1  b2  c1  c2

$ find . \( -name a\* -or -name b\* \)
./a1
./a2
./b1
./b2

$ names="\( -name a\* -or -name b\* \)"

$ printf "%s\n" "$names"
\( -name a\* -or -name b\* \)

$ find . $(printf "%q" "$names")
find: -name\: unknown primary or operator

$ find . $(printf "%s" "$names")
find: \): unknown primary or operator

$ find . $names
find: \): unknown primary or operator

$ find . "$names"
find: \( -name a\* -or -name b\* \): No such file or directory

Em bash v4.1.2(2) , a seguinte instrução simples, escolhida apenas como um exemplo mínimo para demonstrar o problema, fornece uma saída aparentemente aleatória:

$ for n in {0..1000}; do echo "$n"; done | 
  tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null

considerando que o seguinte fornece uma saída consistente:

$ seq 0 10000 | tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null

Especificamente, para a primeira instrução, o sortcomando escolhe trigêmeos consecutivos aparentemente aleatórios (por exemplo, 226.225.224; 52.51.50; 174.173.172; etc.). Para ter uma noção da heterogeneidade da saída, pode-se executar o comando problemático várias vezes e, em seguida, listar o número de possibilidades distintas:

$ seq -w 0 2000 | while read x; do for n in {0..1000}; do echo "$n"; done | 
  tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null | cat > "file_${x}"; done

Contando as ocorrências das várias saídas:

$ for f in file_*; do sort -g "$f" | tail -n3 | paste -sd, ; done  | 
  sort | uniq -c | sort -gk1,1 -k2,2
   1 7,8,9
   1 17,18,19
   1 40,41,42
   1 43,44,45
   1 47,48,49
   1 50,51,52
   1 54,55,56
   1 58,59,60
   1 59,60,61
   1 66,67,68
   1 71,72,73
   1 78,79,80
   1 103,104,105
   1 104,105,106
   1 106,107,108
   1 110,111,112
   1 111,112,113
   1 121,122,123
   1 125,126,127
   1 129,130,131
   1 134,135,136
   1 136,137,138
   1 142,143,144
   1 143,144,145
   1 148,149,150
   1 150,151,152
   1 156,157,158
   1 157,158,159
   1 165,166,167
   1 171,172,173
   1 173,174,175
   1 174,175,176
   1 177,178,179
   1 179,180,181
   1 181,182,183
   1 183,184,185
   1 185,186,187
   1 186,187,188
   1 191,192,193
   1 194,195,196
   1 198,199,200
   1 200,201,202
   1 206,207,208
   1 208,209,210
   1 209,210,211
   1 210,211,212
   1 216,217,218
   1 217,218,219
   1 233,234,235
   1 236,237,238
   1 237,238,239
   1 238,239,240
   1 242,243,244
   1 245,246,247
   1 246,247,248
   1 254,255,256
   1 256,257,258
   1 267,268,269
   1 270,271,272
   1 273,274,275
   1 277,278,279
   1 279,280,281
   1 287,288,289
   1 288,289,290
   1 305,306,307
   1 306,307,308
   1 307,308,309
   1 326,327,328
   1 337,338,339
   1 339,340,341
   1 340,341,342
   1 351,352,353
   1 357,358,359
   1 359,360,361
   1 365,366,367
   1 368,369,370
   1 370,371,372
   1 376,377,378
   1 377,378,379
   1 383,384,385
   1 386,387,388
   1 388,389,390
   1 401,402,403
   1 408,409,410
   1 409,410,411
   1 415,416,417
   1 419,420,421
   1 424,425,426
   1 426,427,428
   1 432,433,434
   1 454,455,456
   1 462,463,464
   1 466,467,468
   1 475,476,477
   1 482,483,484
   1 487,488,489
   1 504,505,506
   1 508,509,510
   1 511,512,513
   1 532,533,534
   1 538,539,540
   1 544,545,546
   1 548,549,550
   1 558,559,560
   1 603,604,605
   1 604,605,606
   1 608,609,610
   1 659,660,661
   1 660,661,662
   1 663,664,665
   1 668,669,670
   1 692,693,694
   1 699,700,701
   1 717,718,719
   1 738,739,740
   1 740,741,742
   1 750,751,752
   1 771,772,773
   1 784,785,786
   1 796,797,798
   1 799,800,801
   1 806,807,808
   1 814,815,816
   1 832,833,834
   1 848,849,850
   1 858,859,860
   1 869,870,871
   1 922,923,924
   1 952,953,954
   1 961,962,963
   1 985,986,987
   2 64,65,66
   2 127,128,129
   2 141,142,143
   2 169,170,171
   2 170,171,172
   2 172,173,174
   2 187,188,189
   2 221,222,223
   2 234,235,236
   2 252,253,254
   2 292,293,294
   2 350,351,352
   2 364,365,366
   2 375,376,377
   2 622,623,624
   2 666,667,668
   3 70,71,72
   3 102,103,104
   3 137,138,139
   3 155,156,157
1826 998,999,1000

mostra que o resultado está correto ~91% das vezes. Omitir a >(head -n2)substituição do processo da teeinstrução resulta na saída correta 100% das vezes. Não vejo por que uma condição de corrida seria relevante para explicar o problema, já que isso deve afetar apenas a ordem relativa da saída de cada uma das substituições do processo na teeinstrução (ou seja, >(head -n2)pode ser concluída primeiro ou >(sort -grk1,1 | head -n3)pode fazê-lo, mas isso deve afetar apenas a ordem de saída, não o resultado em si; seria até compreensível se a saída dos dois comandos fosse intercalada aleatoriamente). Como teedeve distribuir cópias idênticas do stdoutloop para stdincada um >()e como as duas substituições de processo são executadas em sub-shells separados (https://unix.stackexchange.com/a/331199/14960 ), nenhum deve afetar o outro, mas eles interagem claramente. Como explicar a interação? Além disso, como a saída de um loop for/ pode ser distribuída para vários processos independentes por ?whilebashtee