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 sort
comando 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 tee
instruçã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 tee
instruçã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 tee
deve distribuir cópias idênticas do stdout
loop para stdin
cada 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 ?while
bash
tee
head -n2
vai sair depois de ler duas linhas. Entãotee
morrerá (de um SIGPIPE) na próxima vez que ele gravar no pipe parahead
, entãosort
verá eof comotee
na outra extremidade de seu próprio pipe também se foi e classificará as linhas que recebeu até agora.A razão pela qual você está vendo isso com o loop e não com seq é que o loop faz vários
write()
s no canal paratee
e, dependendo do tempo, isso provavelmentetee
fará várias leituras curtas. Enquantoseq
gravará toda a saída de uma só vez,tee
fará apenas umread()
. Se você fizer umseq 1000000
, provavelmente também verá um comportamento aleatório .Para contornar o problema, você precisaria de uma versão
head
que continue lendo depois de produzir as 2 primeiras linhas. Por exemplo, você poderia usarsed '3,$d'
em vez dehead -n2
oused 2q
.Ou use:
para
tee
(apenas) ignorar o SIGPIPE, mas com algumastee
implementações, você veria algumas mensagens de erro por causa da falhawrite()
no pipe.Observe que, embora a saída classificada provavelmente venha depois da não classificada, não há garantia. De maneira mais geral, você não pode realmente garantir a ordem de saída dos programas executados simultaneamente, a menos que haja algo que os coordene.