Output substitusi proses tidak sesuai pesanan

Itu

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

perintah memberikan output yang tak terduga.

Saya membaca ini: Bagaimana proses substitusi diimplementasikan dalam bash? dan banyak artikel lain tentang substitusi proses di internet, tetapi tidak mengerti mengapa ia berperilaku seperti ini.

Output yang diharapkan:

one
two
three

Output nyata:

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

Juga, kedua perintah ini harus setara dari sudut pandang saya, tetapi tidak:

##### 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

Mengapa saya berpikir, mereka harus sama? Karena, keduanya menghubungkan seqoutput ke catinput melalui pipa anonim - Wikipedia, Substitusi proses .

Pertanyaan: Mengapa berperilaku seperti ini? Di mana kesalahan saya? Jawaban komprehensif diinginkan (dengan penjelasan bagaimana bashmelakukannya di bawah tenda).

Ya, bashseperti di ksh( di mana fitur tersebut berasal), proses di dalam proses substitusi tidak menunggu (sebelum menjalankan perintah berikutnya dalam skrip).

untuk <(...)satu, itu biasanya baik seperti di:

cmd1 <(cmd2)

shell akan menunggu cmd1dan cmd1biasanya akan menunggu cmd2berdasarkan pembacaan sampai akhir file pada pipa yang diganti, dan bahwa end-file biasanya terjadi ketika cmd2mati. Itulah alasan yang sama mengapa beberapa kerang (tidak bash) tidak perlu menunggu untuk cmd2masuk cmd2 | cmd1.

Untuk cmd1 >(cmd2), bagaimanapun, bahwa umumnya tidak terjadi, karena lebih cmd2yang biasanya menunggu cmd1di sana sehingga umumnya akan keluar setelah.

Itu sudah diperbaiki zshyang menunggu di cmd2sana (tetapi tidak jika Anda menuliskannya sebagai cmd1 > >(cmd2)dan cmd1bukan bawaan, gunakan {cmd1} > >(cmd2)sebagai gantinya yang didokumentasikan ).

kshtidak menunggu secara default, tetapi memungkinkan Anda menunggu dengan waitbuiltin (itu juga membuat pid tersedia $!, meskipun itu tidak membantu jika Anda melakukannya cmd1 >(cmd2) >(cmd3))

rc(dengan cmd1 >{cmd2}sintaks), sama seperti kshkecuali Anda bisa mendapatkan semua proses latar belakang dengan $apids.

es(juga dengan cmd1 >{cmd2}) menunggu cmd2like in zsh, dan juga menunggu redirections cmd2dalam <{cmd2}proses.

bashmemang membuat pid dari cmd2(atau lebih tepatnya dari subkulit seperti itu berjalan cmd2dalam proses anak dari subkulit itu meskipun itu adalah perintah terakhir di sana) tersedia di $!, tetapi tidak membiarkan Anda menunggu untuk itu.

Jika Anda harus menggunakan bash, Anda dapat mengatasi masalah dengan menggunakan perintah yang akan menunggu kedua perintah dengan:

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

Itu membuat keduanya cmd1dan cmd2memiliki fd 3 terbuka untuk sebuah pipa. catakan menunggu akhir file di ujung yang lain, jadi biasanya hanya akan keluar ketika keduanya cmd1dan cmd2sudah mati. Dan shell akan menunggu catperintah itu. Anda dapat melihat bahwa sebagai jaring untuk menangkap penghentian semua proses latar belakang (Anda dapat menggunakannya untuk hal-hal lain yang dimulai di latar belakang seperti dengan &, coprocs atau bahkan perintah yang melatarbelakangi diri mereka sendiri asalkan mereka tidak menutup semua deskriptor file mereka seperti yang biasanya dilakukan daemon ).

Perhatikan bahwa berkat proses subkulit sia-sia yang disebutkan di atas, ia bekerja bahkan jika cmd2menutup fd 3-nya (perintah biasanya tidak melakukan itu, tetapi beberapa suka sudoatau sshtidak). Versi masa depan pada bashakhirnya dapat melakukan optimasi di sana seperti di shell lain. Maka Anda akan membutuhkan sesuatu seperti:

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

Untuk memastikan masih ada proses shell tambahan dengan fd 3 yang terbuka menunggu sudoperintah itu.

Catatan yang cattidak akan membaca apa pun (karena proses tidak menulis di fd 3 mereka). Itu hanya ada untuk sinkronisasi. Ini akan melakukan hanya satu read()panggilan sistem yang akan kembali tanpa hasil di akhir.

Anda sebenarnya dapat menghindari berjalan catdengan menggunakan substitusi perintah untuk melakukan sinkronisasi pipa:

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

Kali ini, itu shell bukan catyang membaca dari pipa yang ujungnya terbuka pada fd 3 dari cmd1dan cmd2. Kami menggunakan tugas variabel sehingga status keluar dari cmd1tersedia di $?.

Atau Anda bisa melakukan proses substitusi dengan tangan, dan kemudian Anda bahkan bisa menggunakan sistem Anda shkarena itu akan menjadi sintaksis shell standar:

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

meskipun perhatikan seperti disebutkan sebelumnya bahwa tidak semua sh implementasi akan menunggu cmd1setelah cmd2selesai (meskipun itu lebih baik daripada sebaliknya). Waktu itu, $?berisi status keluar dari cmd2; meskipun bashdan zshmembuat cmd1status keluar tersedia di ${PIPESTATUS[0]}dan $pipestatus[1]masing - masing (lihat juga pipefailopsi dalam beberapa shell sehingga $?dapat melaporkan kegagalan komponen pipa selain yang terakhir)

Catatan yang yashmemiliki masalah serupa dengan fitur pengalihan prosesnya .cmd1 >(cmd2)akan ditulis di cmd1 /dev/fd/3 3>(cmd2)sana. Tetapi cmd2tidak menunggu dan Anda tidak dapat menggunakannya waituntuk menunggu dan pidnya tidak tersedia dalam $!variabel juga. Anda akan menggunakan pekerjaan yang sama untuk bash.

Anda dapat menyalurkan perintah kedua ke perintah lain cat , yang akan menunggu sampai pipa inputnya tertutup. Ex:

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

Singkat dan sederhana.

==========

Sesederhana tampaknya, banyak yang terjadi di belakang layar. Anda dapat mengabaikan sisa jawabannya jika Anda tidak tertarik dengan cara kerjanya.

Ketika Anda memiliki echo two > >(cat); echo three, >(cat)dipotong oleh shell interaktif, dan berjalan secara independen echo two. Dengan demikian, echo twoselesai, dan kemudian echo threedieksekusi, tetapi sebelum >(cat)selesai. Ketika bashmendapatkan data dari >(cat)saat itu tidak diharapkan (beberapa milidetik kemudian), itu memberi Anda situasi seperti cepat di mana Anda harus menekan baris baru untuk kembali ke terminal (Sama seperti jika pengguna lain mesgmenyunting Anda).

Namun, mengingat echo two > >(cat) | cat; echo three, dua subkulit muncul (sesuai dokumentasi |simbol).

Satu subkulit bernama A adalah untuk echo two > >(cat), dan satu subkulit bernama B adalah untuk cat. A secara otomatis terhubung ke B (stdout A adalah stdin B). Kemudian, echo twodan >(cat)mulai jalankan. >(cat)stdout diatur ke stdout A, yang sama dengan stdin B. Setelah echo twoselesai, A keluar, menutup stdout-nya. Namun, >(cat)masih memegang referensi ke stdin B. catStdin kedua memegang stdin B, dan itu cattidak akan keluar sampai ia melihat EOF. EOF hanya diberikan ketika tidak ada lagi file yang dibuka dalam mode tulis, jadi >(cat)stdout memblokir yang kedua cat. B tetap menunggu pada detik itu cat. Karena memerah buffer dan keluar. Tidak ada yang memegang stdin B / detik lagi,echo two keluar, >(cat)akhirnya mendapat EOF, jadi>(cat)catcatmembaca EOF (B sama sekali tidak membaca stdin, tidak peduli). EOF ini menyebabkan catbuffer kedua menyiram buffer, menutup stdout, dan keluar, dan kemudian B keluar karenacat keluar dan B sedang menunggu cat.

Peringatan dari ini adalah bahwa bash juga memunculkan subkulit untuk >(cat)! Karena ini, Anda akan melihatnya

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

masih akan menunggu 5 detik sebelum dieksekusi echo three, meskipun sleep 5tidak memegang stdin B. Ini karena subkulit tersembunyi yang ditumbuhkan C >(sleep 5)sedang menunggu sleep, dan C memegang stdin B. Anda bisa lihat caranya

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

Tidak akan menunggu, karena sleeptidak memegang stdin B, dan tidak ada subshell hantu C yang memegang stdin B (eksekutif akan memaksa tidur untuk menggantikan C, yang bertentangan dengan forking dan membuat C menunggu sleep). Terlepas dari peringatan ini,

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

masih akan menjalankan fungsi dengan benar, seperti dijelaskan sebelumnya.