İlerleme raporları / kayıt bilgileri stderr veya stdout'a mı ait?

İlerleme raporları ve kayıt bilgilerinin ("Foo yapmak; foo yapmak" gibi) basılacağı konusunda resmi bir POSIX, GNU veya başka bir kılavuz var mı? Şahsen ben onları stderr'e yazma eğilimindeyim, böylece stdout'u yönlendirebilir ve sadece programın gerçek çıktısını alabilirim. Son zamanlarda, ilerleme raporları aslında hata olmadığından ve sadece hata mesajlarının stderr'e basılması gerektiği için bunun iyi bir uygulama olmadığı söylendi.

Her iki pozisyon da anlamlıdır ve elbette yaptığınız işin detaylarına bağlı olarak birini veya diğerini seçebilirsiniz, ancak bunun için genel kabul görmüş bir standart olup olmadığını bilmek istiyorum. POSIX, GNU kodlama standartları veya bu tür yaygın kabul görmüş en iyi uygulama listelerinde herhangi bir özel kural bulamamıştım.

Birkaç benzer sorumuz var, ancak bu sorunu çözemiyorlar:

• Kabuk komut dosyalarında stderr'e yeniden yönlendirme ne zaman kullanılmalı : Kabul edilen cevap, ne yapma eğiliminde olduğumu, programın son çıktısını stdout'ta ve stderr'de başka bir şeyde tutmayı önerir. Ancak, bu argümanlar tarafından desteklense de, sadece bir kullanıcı görüşü olarak sunulmaktadır.

• Kullanım mesajı stderr'e mi yoksa stdout'a mı gitmeli? : Bu, mesajlara yardımcı olmak için özeldir ancak GNU kodlama standardını gösterir. Bu aradığım bir şey, sadece mesajlara yardımcı olmakla sınırlı değil.

Öyleyse, ilerleme raporlarının ve diğer bilgilendirici mesajların (programın gerçek çıktısının bir parçası olmayan) basılması gerektiği konusunda resmi kurallar var mı?

Posix standart akışları şöyle tanımlar :

Program başlangıcında, üç akış önceden tanımlanacak ve açıkça açılması gerekmeyecektir: standart giriş (geleneksel girişi okumak için), standart çıkış (geleneksel çıkışı yazmak için) ve standart hata (teşhis çıkışını yazmak için). Açıldığında, standart hata akışı tam olarak arabelleğe alınmadı; standart giriş ve standart çıkış akışları, yalnızca akış etkileşimli bir cihaza atıfta bulunmayacak şekilde belirlenebiliyorsa tamamen tamponlanır.

Önceki XIV benzer standart akışları anlatılmaktadır:

Değişken: FILE * stdout
Programdan normal çıktı almak için kullanılan standart çıktı akışı.

Değişken: FILE * stderr
Program tarafından verilen hata mesajları ve teşhis için kullanılan standart hata akışı.

Bu nedenle, standart tanımların “geleneksel / normal çıktı” ve “tanı / hata çıktı” nın ötesinde akış kullanımı için çok az rehberliği var. . Bazı sistemler bile izlemek stderr çıkış için ve ona sorunların bir işareti düşünün. Tamamen yardımcı ilerleme bilgisi bu nedenle her iki akışta da sorunludur.

İlerleme göstergelerini koşulsuz olarak her iki standart akışa göndermek yerine, ilerleme çıktısının yalnızca etkileşimli akışlar için uygun olduğunu kabul etmek önemlidir . Bunu akılda tutarak, ilerleme sayaçlarını yalnızca akışın etkileşimli olup olmadığını (örn. İle isatty()) veya komut satırı seçeneği tarafından açıkça etkinleştirilip etkinleştirilmediğini kontrol ettikten sonra yazmanızı öneririm . Bu,% -complet bar'lar gibi anlam çıkarmak için terminal güncelleme davranışına dayanan ilerleme sayaçları için özellikle önemlidir.

Bazı çok basit ilerleme mesajları için (“X Başlatılıyor” ... “X ile Yapıldı”) etkileşimli olmayan akışlar için bile çıktı eklemek daha uygun olur. Bu durumda, kullanıcıların arama yapmak grepveya sayfalamak lessveya izlemek gibi akışlarla nasıl etkileşime girebileceklerini düşünün tail -f. İlerleme mesajlarını bu bağlamlarda görmek mantıklı olursa, tüketmeleri çok daha kolay olacaktır stdout.

POSIX , standart hatayı şu şekilde tanımlar:

tanılama çıktılarını yazmak için

Bu, yalnızca hata mesajlarıyla kullanımını sınırlamaz. İlerleme bilgisini diyagnostik çıktı olarak kabul ediyorum, bu yüzden standart hataya ait.

POSIX, Shell and Utilities'teki "tanılama bilgileri" hakkında biraz daha somuttur , 1.4: Yardımcı Program Tanım Varsayılanları (benimkine önem verir):

STDERR

STDERR bölümü, yardımcı programın standart hata çıktısını açıklar. Sadece yardımcı program tarafından bilerek gönderilen mesajlar açıklanmaktadır. Standart hata için bir terminal kullanılması, arka planda kullanıldığında standart hata çıktısı yazan standart yardımcı programlardan herhangi birinin durmasına neden olabilir. Bu nedenle, uygulamalar arka planda yerleştirilecek komut dosyalarında etkileşimli özellikler kullanmamalıdır.

Çoğu yardımcı program için tanısal mesajların formatı belirtilmemiştir, ancak formatı POSIX.1-2008'in bu hacmi tarafından belirtilmeyen tanısal ve bilgilendirici mesajların dili ve kültürel kuralları, LC_MESSAGES ve [XSI] [Option Start] ayarlarından etkilenmelidir. ] NLSPATH. [Seçenek Sonu]

Standart hizmet programlarının belirtilen standart hata çıktısı, bu POSIX.1-2008 hacminin sağladığı durumlar haricinde, bu POSIX.1-2008 biriminde tanımlanan çevre değişkenlerinin varlığına veya değerine bağlı olmayacaktır.

Varsayılan Davranış : Bu bölüm "Standart hata yalnızca teşhis mesajları için kullanılacaktır" olarak listelendiğinde, aksi belirtilmediği sürece , tanılama mesajlarının yalnızca çıkış durumu bir hata olduğunu gösterdiğinde standart hataya gönderileceği anlamına gelir. ortaya çıktı ve yardımcı program bu POSIX.1-2008 biriminde açıklandığı şekilde kullanılır.

Bu bölüm "Kullanılmadı" olarak listelendiğinde, hizmet programı POSIX.1-2008'in bu cildinde açıklandığı gibi kullanıldığında standart hatanın kullanılmaması gerektiği anlamına gelir.

IANASL, ancak stderr'ın yalnızca yardımcı program bir hata çıkış kodu döndürürse çıktı alacağı anlamına geldiğini yorumluyorum. Başarılı bir yürütme için bu olayların normal seyri olmaması gerektiği için, bir hata oluşmadıkça (elbette, aksi belirtilmediği sürece) bir POSIX yardımcı programı tarafından ilerleme bilgileri yazdırılmamalıdır .

Dışlama ilkesiyle, sadece stderr'e gidebilir. Evet, stderr'in tanı amaçlı olduğunu belirten Stephen Kitt tarafından verilen POSIX şartnamesiyle bağlantının ötesinde size sunamayacağım resmi bir şartname sorduğunuzu biliyorum.

Daha önemli olan nokta stdin ve stdout'un baskı ilerleme raporlarını stdout'a izin vermeyen bir işleve sahip olması - elbette Unix kabuk komutlarında sadece bir yan etki değil, aynı zamanda güçlü boru hattı yaklaşımının özü olan bir boru dizisi oluştururlar. .

Yani. Programınızın gerçek "yükü" dışında hiçbir şey stdout'a ait değildir. Programınızın çıktısı yoksa, hiçbir şey stdout'a gitmemelidir. Bu , ilerleme raporları da dahil olmak üzere diğer her şey için stderr bırakır .

Verilmiş, bu bir delik bırakır - muhtemelen ne "çıktı" ne de hatalar için olan ama ilerleme raporları, hata ayıklama ve somesuch için olan bir "stdfluff" veya bunun gibi bir şey olması güzel olurdu. Aslında, hiçbir şey sizi bunu gerçekleştirmekten alıkoyamaz, yani ilerlemenizi dosya tanıtıcısına 3 yazdırabilirsiniz. Örnek:

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

Bu hiçbir çıktı üretmez. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

Bu, stdout'a yönlendirilen fd-3'e yazdırır.

(*) İlk örnek çıktı üretmiyor, ancak hala biraz getirildi; openbaşarısız olur ve $!içerecektir no such file or directory; sadece bunu örnek olarak alın, elbette bu şekilde kullanılması ciddi değildir. Gerçek bir programda, bu rotaya gitmek istiyorsanız /dev/fd/3, kullanılabilir olup olmadığını test edebilir ve bunu ilerleme raporlarınızı etkinleştirip etkinleştirmeyeceğinizin ipucu olarak alabilirsiniz; Bunu çok erken yapmak zorunda kalacaksın, böylece opengerçek dosyalar ve benzeri şeyler için kendi kafanla karıştı .

Kullanıcı onu başlattıysa kullanım mesajı stdout'a --helpve bir hata yaptıysa stderr'a gitmelidir . Koşulsuz olarak stderr'e yazdırmak iğrençtir çünkü çağrı cihazı / grep / etc ile görüntülenmesini zorlaştırır.

Ayrıca, üçüncü bir yol önerebilir miyim: İlerleme raporları / iplikçiler / vb. İçin açık / dev / tty.