Вихід процесу заміни не в порядку

The

echo one; echo two > >(cat); echo three; 

команда дає несподіваний вихід.

Я читав це: Як реалізується заміна процесу в bash? та багато інших статей про заміну процесів в Інтернеті, але не розумію, чому так поводиться.

Очікуваний вихід:

one
two
three

Реальний вихід:

prompt$ echo one; echo two > >(cat); echo three;
one
three
prompt$ two

Крім того, ці дві команди мають бути еквівалентними з моєї точки зору, але вони не:

##### first command - the pipe is used.
prompt$ seq 1 5 | cat
1
2
3
4
5
##### second command - the process substitution and redirection are used.
prompt$ seq 1 5 > >(cat)
prompt$ 1
2
3
4
5

Чому я думаю, вони повинні бути однаковими? Тому що, обидва підключає seqвихід до catвходу через анонімну трубку - Wikipedia, Process substitution .

Питання: Чому він так поводиться? Де моя помилка? Потрібна вичерпна відповідь (з поясненням того, як це bashробиться під капотом).

Так, bashяк і в ksh(звідки походить ця функція), процеси всередині заміни процесу не чекають (перед запуском наступної команди в скрипті).

для <(...)одного, це зазвичай добре, як у:

cmd1 <(cmd2)

оболонка буде чекати cmd1і cmd1, як правило, чекає cmd2в силу її зчитування до кінця файлу на трубі, що підміняється, і цей кінець файлу зазвичай відбувається, коли cmd2гине. Це та ж причина , кілька снарядів (НЕ bash) не турбувати чекають cmd2в cmd2 | cmd1.

Бо cmd1 >(cmd2), однак, це взагалі не так, оскільки, як cmd2правило , більше cmd1там чекає, і, як правило, вийде після.

Це зафіксовано в zshтому, що cmd2там чекає (але не, якщо ви пишете це як cmd1 > >(cmd2)і cmd1не вбудовано, використовуйте {cmd1} > >(cmd2)натомість як документально ).

kshне чекає за замовчуванням, але дозволяє зачекати його за допомогою waitвбудованого (він також робить pid доступним у $!, хоча це не допомагає, якщо це зробити cmd1 >(cmd2) >(cmd3))

rc(із cmd1 >{cmd2}синтаксисом), так само, як kshви можете отримати підказки всіх фонових процесів $apids.

es(також з cmd1 >{cmd2}) чекає, cmd2як у zsh, а також чекає cmd2в <{cmd2}перенаправленнях процесів.

bashробить pid cmd2(або точніше підкабелі, оскільки він працює cmd2в дочірньому процесі цієї підпакеті, хоча це остання команда там) доступний $!, але не дозволяє вам чекати на нього.

Якщо вам доведеться використовувати bash, ви можете вирішити проблему, скориставшись командою, яка буде чекати обох команд із:

{ { cmd1 >(cmd2); } 3>&1 >&4 4>&- | cat; } 4>&1

Це робить і те, cmd1і cmd2їх fd 3 відкрито до труби. catбуде чекати закінчення файлу на іншому кінці, тому, як правило, вийде лише тоді, коли вони обидва cmd1та cmd2мертві. І оболонка буде чекати цієї catкоманди. Ви можете бачити, що це як мережа, щоб зафіксувати завершення всіх фонових процесів (ви можете використовувати це для інших речей, розпочатих у фоновому режимі, як, наприклад &, для копроків або навіть команд цього фону за умови, що вони не закривають усі дескриптори файлів, як, наприклад, демони ).

Зауважте, що завдяки тому, що був згаданий вище підзарядний процес, він працює, навіть якщо cmd2закриває свій fd 3 (команди зазвичай цього не роблять, але деякі люблять sudoабо sshроблять). Майбутні версії з bashчасом можуть зробити оптимізацію, як і в інших оболонках. Тоді вам знадобиться щось на кшталт:

{ { cmd1 >(sudo cmd2; exit); } 3>&1 >&4 4>&- | cat; } 4>&1

Щоб переконатися, що ще існує додатковий процес оболонки з тим відкритим fd 3, що чекає цієї sudoкоманди.

Зауважте, що catнічого не буде прочитано (оскільки процеси не записують на їх fd 3). Це просто для синхронізації. Він здійснить лише один read()системний виклик, який повернеться без нічого в кінці.

Насправді ви можете уникнути запуску cat, використовуючи заміну команди для синхронізації труби:

{ unused=$( { cmd1 >(cmd2); } 3>&1 >&4 4>&-); } 4>&1

Цього разу оболонка замість catцього зчитується з труби, інший кінець якої відкритий на fd 3 cmd1та cmd2. Ми використовуємо присвоєння змінної, щоб статус виходу cmd1був доступний у $?.

Або ви можете зробити заміну процесу вручну, і тоді ви можете навіть використовувати систему вашої системи, shоскільки це стане стандартним синтаксисом оболонки:

{ cmd1 /dev/fd/3 3>&1 >&4 4>&- | cmd2 4>&-; } 4>&1

хоча зауважте, як зазначалося раніше, що не всі shреалізації будуть чекати cmd1після cmd2закінчення (хоча це краще, ніж навпаки). Цей час $?містить статус виходу cmd2; хоча bashі zshзробіть cmd1статус виходу доступним відповідно ${PIPESTATUS[0]}і $pipestatus[1]відповідно (див. також pipefailопцію в декількох оболонках, щоб $?можна було повідомити про вихід інших трубних компонентів, ніж останній)

Зауважте, що у yashнього є аналогічні проблеми з функцією перенаправлення процесу . cmd1 >(cmd2)писали б cmd1 /dev/fd/3 3>(cmd2)там. Але cmd2його не чекають, і ви також не можете waitйого чекати, і його pid також не доступний у $!змінній. Ви б використовували ті самі роботи, що і для bash.

Ви можете передати другу команду в іншу cat, яка буде чекати, поки її вхідна труба не закриється. Наприклад:

prompt$ echo one; echo two > >(cat) | cat; echo three;
one
two
three
prompt$

Короткий і простий.

==========

Настільки просто, як здається, багато чого відбувається за лаштунками. Ви можете проігнорувати решту відповідей, якщо вас не цікавить, як це працює.

Коли у вас є echo two > >(cat); echo three, >(cat)він розщеплений інтерактивною оболонкою і працює незалежно від echo two. Таким чином, echo twoзакінчується, а потім echo threeвиконується, але до >(cat)закінчення. Коли bashотримує дані від того, >(cat)коли цього не очікували (через пару мілісекунд), це дає вам таку швидку ситуацію, коли вам доведеться натиснути нову лінію, щоб повернутися до терміналу (Те саме, як якщо б інший користувач mesgвас редагував).

Однак, з огляду на те echo two > >(cat) | cat; echo three, що два подушечки породжуються (згідно документації |символу).

Одна піддіаграма з ім'ям A призначена для echo two > >(cat), а одна підгрупа з назвою B призначена для cat. A автоматично підключається до B (викладка A - stdin B). Потім echo twoі >(cat)починайте виконувати. >(cat)'s stoutout' встановлюється в 'stdout' A, що дорівнює stdin B. Після echo twoзакінчення A виходить, закриваючи свою виворіт. Тим не менш, >(cat)досі тримається посилання на STdin. Другий catstdin утримує stdin B, і catвін не вийде, поки він не побачить EOF. EOF надається лише тоді, коли ніхто не має відкритого файлу в режимі запису, тому >(cat)stdout блокує другий cat. Б залишається чекати тієї секунди cat. З моменту echo twoвиходу >(cat)зрештою отримує EOF, значить>(cat)змиває буфер і виходить. Ніхто більше не тримає BD / секунду catstdin, тому другий catчитає EOF (B зовсім не читає його stdin, це не хвилює). Цей EOF змушує другий catзмивати свій буфер, закривати його stdout і виходити, а потім B виходить, тому що catвийшов, а B чекав на cat.

Застереження цього полягає в тому, що баш також породжує нижню частину >(cat)! Через це ви це побачите

echo two > >(sleep 5) | cat; echo three

ще будете чекати 5 секунд перед виконанням echo three, навіть якщо sleep 5він не тримає BD. Це пояснюється тим, що чекає прихований підмножина C, породжена для >(sleep 5)якої sleep, і C тримає стдин B. Ви можете бачити, як

echo two > >(exec sleep 5) | cat; echo three

Однак не чекатимемо, оскільки sleepне тримає stdin B, і немає жодної привидної підпрограми C, яка тримає stdin B (exec змусить сон замінити C, на відміну від розщеплення і змушення C чекати sleep). Незалежно від цього застереження,

echo two > >(exec cat) | cat; echo three

все одно належним чином виконуватимуть функції в порядку, як описано раніше.