In che modo l'ordine di esecuzione nella shell in relazione al reindirizzamento è sconvolto circa 1 volta su 1000 sul sistema?

Considerando queste domande e risposte sull'ordine di esecuzione nella shell in relazione al reindirizzamento, e nonostante il fatto che se un file non esiste viene creato prima in modo che cat example.txt | shuf > example.txt non si lamenta del fatto che il file non esiste - il che conferma semplicemente l'ordine da quello che ho capito - allora perché circa una volta ogni mille sul mio sistema lo shuffle funziona quando lo faccio (il backup contiene 15 valori statici ciascuno su loro linea)

for i in $(seq 1 1000); do
    cp backup test
    echo $i
    cat test | shuf > test
    cat test
done

Come può esserci apparentemente un'eccezione alla regola?

Risposta accettata:

Qui:

cat test | shuf > test

> ha la precedenza nel senso che ciò significa:

(cat test) | (shuf > test) 

e non:

(cat test | shuf) > test

Anche se se usassimo due file diversi, non ci sarebbe comunque alcuna differenza tra questi due raggruppamenti.

Ciò che diventa significativo quando si utilizza lo stesso file è che i due comandi su entrambi i lati della pipe eseguono contemporaneamente . Questi comandi sono cat test e shuf > test . > significa "aperto per scrivere e troncare", mentre cat sta per "aprire per la lettura", leggere e chiudere. Dal momento che queste due cose stanno accadendo contemporaneamente , il rapporto tra l'ordine delle loro operazioni collettive è indeterminato . C'è una possibilità che cat otterrà lo slurp del file prima che la shell gestisca shuf > test lo tronca. Ma questa è una piccola possibilità, dal momento che c'è più coinvolto; accadrà solo se cat è molto fortunato in relazione alla programmazione di shuf > test .

Morale della favola: Non farlo:usa invece due file.