Kabuk komut dosyalarında stderr'e yeniden yönlendirme ne zaman kullanılır?

15

Grep çıktı stdout "normal" mesajları ve stderr hata mesajları gibi iyi davrandım yardımcı programları biliyorum .

$ grep '^foo' file1 file2
file1:foo
grep: file2: No such file or directory

Kabuk betikleri kendim yazarken, hangi çıktıyı ve hangi mesajları stderr'de sunmam gerektiğine veya hiç rahatsız etmem gerektiğine karar vermekte zorlanırım.

İyi uygulama hakkında bilmek istiyorum: Bir mesajı stderr'a ne zaman yeniden yönlendirmek istenir ve makul olur, ne zaman yapılmaz?

Elbette, "bağlıdır", ancak bu kararları vermeme yardımcı olacak bazı görüşleriniz var mı?

Bu sübjektif soruyu formata uygun hale getirmek için, "neden" e yönelik cevapları teşvik etmek istiyorum ve deneyimle ve mümkünse gerçeklerle desteklenerek bilgilendirilirim.

— glts
kaynak

@rush mükemmel bir şekilde açıklıyor. Uzun komut dosyaları için genellikle ilerleme raporlarını stderr'a yazdırırım.

— terdon

12

Kabuk betikleri kendim yazarken, hangi çıktıyı ve hangi mesajları stderr'de sunmam gerektiğine veya hiç rahatsız etmem gerektiğine karar vermekte zorlanırım.

Sükut altındır. Her şey yolundaysa hiçbir şey çıktı almayın.

İyi uygulama hakkında bilmek istiyorum: Bir mesajı stderr'a ne zaman yeniden yönlendirmek istenir ve makul olur, ne zaman yapılmaz?

Stderr'i stdout'tan ayırmanın en kolay yolu: tüm komut dosyası çıktılarınızın boru yoluyla başka bir komuta yönlendirileceğini hayal edin. Bu durumda, stdout'taki beklenmedik bilgiler boru dizisini bozabileceğinden, tüm bildirimleri stderr'de tutmalısınız.

Ayrıca bazen bunun gibi borularda:

command1 | while read line ; do command2 ; done | command3

command2kullanıcı çıkışına bir şey iletmeniz gerekir . Geçici dosyalar olmadan en kolay yol stderr'dir.

— acele
kaynak

"Pip düşünün" fikri için teşekkür ederiz. Bazen "bildirmek" dışında hiçbir şey yapmayan komut dosyaları dağıtırım ( echobazı değişkenler, neler yapıldığını gösterir, ilerleme gösterir). Ben bu günlük mesajları tüm script hiç çıkacak çünkü stderr her şeyi koymak için tereddüt. Bu durumlarda boru fikrinin nasıl uygulanacağından emin değilim.

— glts

1

@glts programları her zaman değiştirilmekte ve geliştirilmektedir. Bahsettiğiniz komut dosyaları şu anda herhangi bir veri vermiyor olsa da, daha sonra olabilir veya bunu yapan diğer komut dosyaları için başlangıç noktası olarak kullanabilirsiniz. Başlamak için sözleşmeyi izlerseniz, daha sonra çok daha az sürpriz alırsınız. OTOH, çıktıyı bir dosyaya kaydetmek istiyorsanız, stderr'i yeniden yönlendirmeniz gerekir, bu yüzden her şey gibi bir ödünleşmedir.

— Joe

+1 Başka bir açıklama: stdout'un her zaman makinede okunabilir olduğundan veya en azından tutarlı bir biçimde yararlı metin verileri içerdiğinden emin olun.

— üçlü

2

Genellikle uygulama işlemi ile ilgili her şeyi yazıyorum stderr, stdoutveri için ayrılmıştır.

Gibi bir uygulama düşünün cat. Girişi okumak ve başka bir uygulamaya (kanal aracılığıyla) iletmek için kullandığınızda, çıkışın durum mesajlarıyla dolmasını istemezsiniz.

Başka bir uygulama için ilginç olabilecek her şey veya benim uygulama için bir postprocessor gidecek stdout, sadece benim uygulama interna ile ilgili her şey olacak stderr.

— Der Hochstapler
kaynak

0

Kişisel tercihim hata mesajları, istisnalar stderrve bilgilendirici mesajlar göndermektir stdout. IMO, stderrher türlü istisna ve dolayısıyla benim konvansiyonum içindir.

— unxnut
kaynak