รายงานความคืบหน้า / ข้อมูลการบันทึกเป็นของ stderr หรือ stdout หรือไม่?

มี POSIX, GNU อย่างเป็นทางการหรือแนวทางอื่น ๆ หรือไม่ว่ารายงานความคืบหน้าและข้อมูลการบันทึก (สิ่งต่าง ๆ เช่น "Doing foo; foo done") ควรพิมพ์ออกมาหรือไม่? โดยส่วนตัวแล้วฉันมักจะเขียนถึง stderr เพื่อที่ฉันจะสามารถเปลี่ยนเส้นทาง stdout และรับเอาท์พุทจริงของโปรแกรมเท่านั้น ฉันเพิ่งบอกว่านี่ไม่ใช่วิธีปฏิบัติที่ดีเนื่องจากรายงานความคืบหน้าไม่ใช่ข้อผิดพลาดจริง ๆ และควรพิมพ์เฉพาะข้อความข้อผิดพลาดไปยัง stderr

ทั้งสองตำแหน่งมีเหตุผลและแน่นอนว่าคุณสามารถเลือกอย่างใดอย่างหนึ่งขึ้นอยู่กับรายละเอียดของสิ่งที่คุณกำลังทำอยู่ แต่ฉันอยากจะรู้ว่ามีมาตรฐานที่ยอมรับกันโดยทั่วไปสำหรับเรื่องนี้หรือไม่ ฉันไม่สามารถค้นหากฎเฉพาะใน POSIX มาตรฐานการเข้ารหัสของ GNU หรือรายการแนวทางปฏิบัติที่ดีที่สุดอื่น ๆ

เรามีคำถามที่คล้ายกันสองสามข้อ แต่พวกเขาไม่ได้แก้ไขปัญหาที่แน่นอนนี้:

• เมื่อใดที่จะใช้การเปลี่ยนเส้นทางไปยัง stderr ในเชลล์สคริปต์ : คำตอบที่ได้รับการยอมรับแสดงให้เห็นสิ่งที่ฉันมักจะทำเอาท์พุทสุดท้ายของโปรแกรมไว้ที่ stdout และทุกอย่างจะเป็น stderr อย่างไรก็ตามนี่เป็นเพียงความเห็นของผู้ใช้แม้ว่าจะได้รับการสนับสนุนจากการขัดแย้ง

• ข้อความการใช้งานควรไปที่ stderr หรือ stdout หรือไม่ : นี่เป็นข้อความเฉพาะสำหรับช่วยเหลือข้อความ แต่อ้างอิงมาตรฐานการเข้ารหัสของ GNU นี่คือสิ่งที่ฉันกำลังมองหาไม่ จำกัด เฉพาะเพื่อช่วยส่งข้อความเท่านั้น

ดังนั้นมีกฎอย่างเป็นทางการว่ารายงานความคืบหน้าและข้อความที่ให้ข้อมูลอื่น ๆ (ซึ่งไม่ได้เป็นส่วนหนึ่งของผลลัพธ์ที่แท้จริงของโปรแกรม) ควรจะพิมพ์หรือไม่

Posix กำหนดสตรีมมาตรฐานดังนี้ :

เมื่อเริ่มต้นโปรแกรมจะต้องกำหนดสามสตรีมไว้ล่วงหน้าและไม่จำเป็นต้องเปิดอย่างชัดเจน: อินพุตมาตรฐาน (สำหรับการอ่านอินพุตดั้งเดิม), เอาต์พุตมาตรฐาน (สำหรับการเขียนเอาต์พุตทั่วไป) และข้อผิดพลาดมาตรฐาน (สำหรับการเขียนเอาต์พุตการวินิจฉัย) เมื่อเปิดสตรีมข้อผิดพลาดมาตรฐานจะไม่ถูกบัฟเฟอร์อย่างสมบูรณ์ อินพุตมาตรฐานและสตรีมเอาต์พุตมาตรฐานจะถูกบัฟเฟอร์อย่างสมบูรณ์หากว่าสามารถกำหนดสตรีมไม่ให้อ้างอิงถึงอุปกรณ์แบบโต้ตอบได้

GNU C Libraryอธิบายลำธารมาตรฐานใกล้เคียงกัน:

ตัวแปร: FILE * stdout
เอาต์พุตสตรีมมาตรฐานซึ่งใช้สำหรับเอาต์พุตปกติจากโปรแกรม

ตัวแปร: FILE * stderr
สตรีมข้อผิดพลาดมาตรฐานซึ่งใช้สำหรับข้อความแสดงข้อผิดพลาดและการวินิจฉัยที่ออกโดยโปรแกรม

ดังนั้นคำจำกัดความมาตรฐานจึงมีคำแนะนำเล็กน้อยสำหรับการใช้งานสตรีมนอกเหนือจาก“ เอาท์พุททั่วไป / ปกติ” และ“ เอาต์พุตการวินิจฉัย / ข้อผิดพลาด” ในทางปฏิบัติมันเป็นเรื่องธรรมดาที่จะเปลี่ยนเส้นทางสตรีมเหล่านี้ไปยังไฟล์และท่อ . บางระบบตรวจสอบ stderrผลลัพธ์และพิจารณาว่าเป็นสัญญาณของปัญหา ข้อมูลความคืบหน้าอย่างหมดจดจึงเป็นปัญหาในสตรีมทั้งสอง

แทนที่จะส่งตัวบ่งชี้ความคืบหน้าโดยไม่มีเงื่อนไขไปยังสตรีมมาตรฐานทั้งสองสิ่งสำคัญคือต้องตระหนักว่าเอาต์พุตความคืบหน้านั้นเหมาะสมสำหรับสตรีมแบบโต้ตอบเท่านั้น โดยที่ในใจผมขอแนะนำให้เขียนเคาน์เตอร์ความคืบหน้าเฉพาะหลังจากตรวจสอบว่ากระแสนั้นเป็นแบบโต้ตอบ (เช่นด้วยisatty()) หรือเมื่อเปิดใช้งานอย่างชัดเจนโดยตัวเลือกบรรทัดคำสั่ง นั่นเป็นสิ่งสำคัญอย่างยิ่งสำหรับมาตรวัดความก้าวหน้าที่ต้องอาศัยพฤติกรรมการอัพเดทเทอร์มินัลเพื่อให้เหมาะสมเช่นแถบ% -complete

สำหรับข้อความแสดงความคืบหน้าอย่างง่าย ๆ บางข้อความ (“ การเริ่มต้น X” ... “ เสร็จสิ้นด้วย X”) มีเหตุผลมากกว่าที่จะรวมเอาท์พุทแม้สำหรับสตรีมแบบไม่โต้ตอบ ในกรณีที่พิจารณาวิธีการที่ผู้ใช้อาจโต้ตอบกับลำธารเช่นการค้นหาด้วยgrepหรือเพจด้วยหรือการตรวจสอบด้วยless ถ้ามันทำให้ความรู้สึกที่จะเห็นข้อความความคืบหน้าในบริบทเหล่านั้นพวกเขาจะง่ายขึ้นที่จะบริโภคจากtail -fstdout

POSIX กำหนดข้อผิดพลาดมาตรฐานเป็น

สำหรับการเขียนเอาต์พุตการวินิจฉัย

สิ่งนี้ไม่ จำกัด การใช้ข้อความแสดงข้อผิดพลาดเท่านั้น ฉันจะพิจารณาข้อมูลความคืบหน้าเป็นเอาต์พุตการวินิจฉัยดังนั้นมันจึงเป็นข้อผิดพลาดมาตรฐาน

POSIX มีรูปธรรมมากขึ้นเล็กน้อยเกี่ยวกับ "ข้อมูลการวินิจฉัย" ในเชลล์และยูทิลิตี้ , 1.4: ยูทิลิตี้คำอธิบายค่าเริ่มต้น (เหมืองของฉัน):

STDERR

ส่วน STDERR อธิบายเอาต์พุตข้อผิดพลาดมาตรฐานของยูทิลิตี้ เฉพาะข้อความที่ถูกส่งโดยยูทิลิตีโดยเจตนาเท่านั้นที่จะได้รับการอธิบาย การใช้เทอร์มินัลสำหรับข้อผิดพลาดมาตรฐานอาจทำให้ยูทิลิตี้มาตรฐานใด ๆ ที่เขียนเอาต์พุตข้อผิดพลาดมาตรฐานหยุดเมื่อใช้ในพื้นหลัง ด้วยเหตุผลนี้แอปพลิเคชันไม่ควรใช้คุณสมบัติการโต้ตอบในสคริปต์เพื่อวางไว้ในพื้นหลัง

รูปแบบของข้อความการวินิจฉัยสำหรับยูทิลิตี้ส่วนใหญ่จะไม่ได้รับการระบุ แต่การประชุมภาษาและวัฒนธรรมของข้อความการวินิจฉัยและข้อมูลที่มีรูปแบบที่ไม่ได้ระบุโดยปริมาณของ POSIX.1-2008 นี้ควรได้รับผลกระทบจากการตั้งค่า LC_MESSAGES และ [XSI] ] NLSPATH [ตัวเลือกท้าย]

เอาต์พุตข้อผิดพลาดมาตรฐานที่ระบุของยูทิลิตี้มาตรฐานจะต้องไม่ขึ้นอยู่กับการมีอยู่หรือค่าของตัวแปรสภาพแวดล้อมที่กำหนดในเล่มนี้ของ POSIX.1-2008 ยกเว้นตามที่กำหนดไว้ในไดรฟ์ข้อมูลของ POSIX.1-2008 นี้

พฤติกรรมเริ่มต้น : เมื่อส่วนนี้ถูกระบุว่าเป็น "ข้อผิดพลาดมาตรฐานจะใช้สำหรับข้อความการวินิจฉัยเท่านั้น" หมายความว่าเว้นแต่จะระบุไว้เป็นอย่างอื่นข้อความการวินิจฉัยจะถูกส่งไปยังข้อผิดพลาดมาตรฐานเฉพาะเมื่อสถานะทางออกบ่งชี้ว่ามีข้อผิดพลาด ที่เกิดขึ้นและใช้งานยูทิลิตี้ตามที่อธิบายไว้ในโวลุ่มนี้ของ POSIX.1-2008

เมื่อส่วนนี้แสดงรายการเป็น "ไม่ได้ใช้" หมายความว่าข้อผิดพลาดมาตรฐานจะไม่ถูกใช้เมื่อใช้ยูทิลิตี้ตามที่อธิบายไว้ในเล่มนี้ของ POSIX.1-2008

IANASL แต่ฉันตีความว่าหมายความว่า stderr จะมีเอาต์พุตเฉพาะถ้ายูทิลิตี้จะส่งคืนรหัสออกจากข้อผิดพลาด เนื่องจากสิ่งนี้ไม่ควรเป็นเหตุการณ์ปกติสำหรับการดำเนินการที่ประสบความสำเร็จจึงไม่ควรพิมพ์ข้อมูลความคืบหน้าโดยยูทิลิตี้ POSIX เว้นแต่ว่ามีข้อผิดพลาดเกิดขึ้น (เว้นแต่แน่นอนที่ระบุไว้เป็นอย่างอื่นเป็นต้น)

โดยหลักการของการกีดกันมันสามารถไปที่ stderr เท่านั้น ใช่ฉันรู้ว่าคุณถามเกี่ยวกับข้อมูลจำเพาะอย่างเป็นทางการซึ่งฉันไม่สามารถนำเสนอคุณเกินกว่าลิงก์ไปยังข้อมูลจำเพาะ POSIX ที่กำหนดโดย Stephen Kitt ซึ่งระบุว่า stderr นั้นมีวัตถุประสงค์เพื่อการวินิจฉัย

จุดที่สำคัญกว่านั้นคือ stdin และ stdout มีฟังก์ชั่นที่ไม่สามารถพิมพ์รายงานความคืบหน้าไปยัง stdout ได้แน่นอนว่ามันจะสร้างลำดับของท่อซึ่งในคำสั่ง Unix shell ไม่ได้เป็นเพียงผลข้างเคียงเท่านั้น .

ดังนั้น. ไม่มีอะไรยกเว้น "payload" ที่แท้จริงของโปรแกรมของคุณที่เป็นของ stdout หากโปรแกรมของคุณไม่มีเอาต์พุตไม่ควรไปที่ stdout สิ่งนี้ทำให้ stderr สำหรับทุกอย่างรวมถึงรายงานความคืบหน้า

จริงอยู่ที่นี่ปล่อยให้เป็นรู - มันอาจจะดีถ้ามี "stdfluff" หรืออะไรทำนองนั้นที่ไม่ใช้สำหรับเอาท์พุทหรือข้อผิดพลาด แต่รายงานความคืบหน้า ในความเป็นจริงไม่มีสิ่งใดขัดขวางไม่ให้คุณทำเช่นนั้นคุณสามารถพิมพ์ความคืบหน้าของคุณไปยังไฟล์ descriptor 3 ตัวอย่าง:

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

สิ่งนี้ไม่สร้างผลลัพธ์ (*)

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

นี่จะพิมพ์ไปยัง fd-3 ซึ่งจะถูกเปลี่ยนเส้นทางไปยัง stdout

(*) ตัวอย่างแรกไม่สร้างเอาต์พุต แต่ยังคงดึงข้อมูลได้ไกล ความopenล้มเหลวและ$!จะมีno such file or directory; เพียงใช้สิ่งนี้เป็นตัวอย่างแน่นอนว่าไม่ควรใช้อย่างนี้อย่างจริงจัง ในโปรแกรมจริงหากคุณต้องการใช้เส้นทางนี้คุณสามารถทดสอบว่า/dev/fd/3ใช้งานได้หรือไม่และใช้เป็นคำใบ้ว่าจะเปิดใช้งานรายงานความคืบหน้าของคุณหรือไม่ คุณต้องทำมันให้เร็วเพื่อที่คุณจะได้ไม่สับสนopenกับไฟล์จริงและ ...

ข้อความการใช้งานควรไปที่ stdout หากผู้ใช้เรียกใช้ด้วย--helpและไปที่ stderr หากพวกเขาทำผิดพลาด การพิมพ์ไปยัง stderr โดยไม่มีเงื่อนไขนั้นน่ารังเกียจเพราะทำให้การดูด้วยเพจเจอร์ / grep / etc ทำได้ยากขึ้น

นอกจากนี้ฉันขอแนะนำวิธีที่สาม: เปิด / dev / tty สำหรับรายงานความคืบหน้า / สปินเนอร์ / ฯลฯ