สับสนเกี่ยวกับ stdin, stdout และ stderr หรือไม่

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

สิ่งที่ฉันอยากรู้คือจุดประสงค์ของไฟล์เหล่านี้คืออะไรตอบคำถามด้วยศัพท์แสงทางเทคโนโลยีน้อยมาก!

อินพุตมาตรฐาน - นี่คือตัวจัดการไฟล์ที่กระบวนการของคุณอ่านเพื่อรับข้อมูลจากคุณ

เอาต์พุตมาตรฐาน - กระบวนการของคุณเขียนข้อมูลปกติไปยังตัวจัดการไฟล์นี้

ข้อผิดพลาดมาตรฐาน - กระบวนการของคุณเขียนข้อมูลข้อผิดพลาดไปยังตัวจัดการไฟล์นี้

นั่นเป็นเรื่องที่โง่เง่าที่สุดเท่าที่จะทำได้ :-)

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

เมื่อกระบวนการของคุณเริ่มต้นมันควรเปิดตัวจัดการเหล่านี้แล้วและสามารถอ่านและ / หรือเขียนได้

โดยค่าเริ่มต้นพวกมันอาจเชื่อมต่อกับอุปกรณ์เทอร์มินัลของคุณ (เช่น/dev/tty) แต่เชลล์จะอนุญาตให้คุณตั้งค่าการเชื่อมต่อระหว่างมือจับเหล่านี้กับไฟล์และ / หรืออุปกรณ์ที่เฉพาะเจาะจง กิจวัตรที่เป็นไปได้ค่อนข้างฉลาด)

ตัวอย่างการ:

my_prog <inputfile 2>errorfile | grep XYZ

ซึ่งจะ:

• my_progสร้างกระบวนการหา
• เปิดinputfileเป็นอินพุตมาตรฐานของคุณ (ตัวจัดการไฟล์ 0)
• เปิดerrorfileเป็นข้อผิดพลาดมาตรฐานของคุณ (จัดการไฟล์ 2)
• สร้างอีกgrepกระบวนการ
• แนบออกมาตรฐานของการเข้ามาตรฐานของmy_proggrep

แสดงความคิดเห็นของคุณอีกครั้ง:

เมื่อฉันเปิดไฟล์เหล่านี้ในโฟลเดอร์ / dev ฉันจะไม่เห็นผลลัพธ์ของกระบวนการที่กำลังทำงานอยู่ได้อย่างไร

เป็นเพราะพวกเขาไม่ใช่ไฟล์ปกติ ในขณะที่ UNIX นำเสนอทุกอย่างเป็นไฟล์ในระบบไฟล์บางที่ไม่ได้ทำให้มันอยู่ในระดับต่ำสุด ไฟล์ส่วนใหญ่ใน/devลำดับชั้นเป็นอุปกรณ์ตัวอักษรหรือบล็อกซึ่งเป็นไดรเวอร์อุปกรณ์ได้อย่างมีประสิทธิภาพ ไม่มีขนาด แต่มีหมายเลขอุปกรณ์หลักและรอง

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

เช่นเดียวกับ/procระบบไฟล์Linux สิ่งเหล่านี้ไม่ใช่ไฟล์จริงเพียงควบคุมเกตเวย์ข้อมูลของเคอร์เนลอย่างแน่นหนา

มันจะถูกต้องมากขึ้นที่จะกล่าวว่าstdin, stdoutและstderrเป็น "I / O ลำธาร" มากกว่าไฟล์ อย่างที่คุณสังเกตเห็นเอนทิตีเหล่านี้ไม่ได้อยู่ในระบบไฟล์ แต่ปรัชญา Unix ที่เกี่ยวข้องกับ I / O คือ "ทุกอย่างเป็นไฟล์" ในทางปฏิบัติที่จริงๆหมายความว่าคุณสามารถใช้ฟังก์ชั่นห้องสมุดเดียวกันและอินเตอร์เฟซ ( printf, scanf, read, write, selectฯลฯ ) โดยไม่ต้องกังวลเกี่ยวกับว่ากระแส I / O ที่จะเชื่อมต่อกับแป้นพิมพ์แฟ้มดิสก์, ซ็อกเก็ต, ท่อ หรือนามธรรม I / O อื่น ๆ

โปรแกรมส่วนใหญ่จะต้องอ่านอินพุตเขียนส่งออกและล็อกข้อผิดพลาดดังนั้นstdin, stdoutและstderrกำหนดไว้ล่วงหน้าสำหรับคุณเป็นความสะดวกสบายในการเขียนโปรแกรม นี่เป็นเพียงการประชุมและไม่ได้บังคับใช้โดยระบบปฏิบัติการ

ในฐานะที่เป็นส่วนเสริมของคำตอบข้างต้นต่อไปนี้เป็นการสรุปเกี่ยวกับการเปลี่ยนเส้นทาง:

แก้ไข: กราฟิกนี้ไม่ถูกต้องทั้งหมด แต่ฉันไม่แน่ใจว่าทำไม ...

กราฟิกบอกว่า 2> & 1 มีผลเหมือนกับ &>

ls Documents ABC > dirlist 2>&1
#does not give the same output as 
ls Documents ABC > dirlist &>

ฉันกลัวว่าความเข้าใจของคุณจะถอยหลังอย่างสมบูรณ์ :)

คิดว่า "standard in", "standard out" และ "error error" จากมุมมองของโปรแกรมไม่ใช่จากมุมมองของเคอร์เนล

เมื่อโปรแกรมต้องการพิมพ์ผลลัพธ์ปกติจะพิมพ์เป็น "standard out" โดยปกติแล้วโปรแกรมจะพิมพ์เอาต์พุตไปยังเอาต์พุตมาตรฐานprintfซึ่งพิมพ์เฉพาะกับเอาต์พุตมาตรฐาน

เมื่อโปรแกรมต้องการพิมพ์ข้อมูลข้อผิดพลาด (ไม่จำเป็นต้องมีข้อยกเว้นนี่คือโครงสร้างภาษาโปรแกรมที่กำหนดไว้ในระดับที่สูงกว่ามาก) โดยปกติจะพิมพ์เป็น "ข้อผิดพลาดมาตรฐาน" โดยปกติจะทำเช่นนั้นด้วยfprintfซึ่งยอมรับกระแสไฟล์ที่จะใช้เมื่อพิมพ์ สตรีมไฟล์อาจจะไฟล์ใด ๆ ที่เปิดสำหรับการเขียน: ออกมาตรฐานข้อผิดพลาดมาตรฐานหรือไฟล์อื่น ๆ ที่ได้รับการเปิดด้วยหรือfopenfdopen

"มาตรฐาน" จะใช้เมื่อแฟ้มต้องการที่จะอ่านเข้าใช้freadหรือหรือfgetsgetchar

ไฟล์ใด ๆ เหล่านี้สามารถเปลี่ยนเส้นทางได้ง่ายจากเชลล์เช่นนี้

cat /etc/passwd > /tmp/out     # redirect cat's standard out to /tmp/foo
cat /nonexistant 2> /tmp/err   # redirect cat's standard error to /tmp/error
cat < /etc/passwd              # redirect cat's standard input to /etc/passwd

หรือ enchilada ทั้งหมด:

cat < /etc/passwd > /tmp/out 2> /tmp/err

มีข้อแม้ที่สำคัญสองประการประการแรก "มาตรฐานใน", "มาตรฐานออก" และ "ข้อผิดพลาดมาตรฐาน" เป็นเพียงการประชุม มันเป็นแบบแผนที่แข็งแกร่งมากแต่เป็นเพียงข้อตกลงที่ดีมากที่จะสามารถเรียกใช้โปรแกรมเช่นนี้: grep echo /etc/services | awk '{print $2;}' | sortและให้เอาต์พุตมาตรฐานของแต่ละโปรแกรมเชื่อมต่อกับอินพุตมาตรฐานของโปรแกรมถัดไปในไพพ์ไลน์

ประการที่สองฉันได้รับฟังก์ชั่น ISO C มาตรฐานสำหรับการทำงานกับสตรีมไฟล์ ( FILE *วัตถุ) - ที่ระดับเคอร์เนลมันเป็นตัวอธิบายไฟล์ทั้งหมด ( intอ้างอิงถึงตารางไฟล์) และการดำเนินงานระดับต่ำเช่นreadและwriteซึ่งไม่ได้ ทำบัฟเฟอร์ความสุขของฟังก์ชั่น ISO C ฉันคิดว่าจะทำให้มันง่ายและใช้ฟังก์ชั่นที่ง่ายขึ้น แต่ฉันคิดว่าเหมือนกันทั้งหมดที่คุณควรรู้ทางเลือก :)

stdin

อ่านอินพุตผ่านคอนโซล (เช่นอินพุตคีย์บอร์ด) ใช้ใน C พร้อมกับ scanf

scanf(<formatstring>,<pointer to storage> ...);

stdout

สร้างเอาต์พุตไปยังคอนโซล ใช้ใน C กับ printf

printf(<string>, <values to print> ...);

stderr

สร้างเอาต์พุต 'ข้อผิดพลาด' ไปยังคอนโซล ใช้ใน C กับ fprintf

fprintf(stderr, <string>, <values to print> ...);

การเปลี่ยนเส้นทาง

แหล่งที่มาสำหรับ stdin สามารถเปลี่ยนเส้นทาง ตัวอย่างเช่นแทนที่จะมาจากการป้อนข้อมูลด้วยแป้นพิมพ์อาจมาจากไฟล์ ( echo < file.txt) หรือโปรแกรมอื่น ( ps | grep <userid>)

ปลายทางสำหรับ stdout, stderr ยังสามารถเปลี่ยนเส้นทางได้ ยกตัวอย่างเช่น stdout สามารถเปลี่ยนเส้นทางไปยังแฟ้ม: ในกรณีนี้การส่งออกจะถูกเขียนไปยังแฟ้ม ls . > ls-output.txt stderr สามารถเปลี่ยนเส้นทางด้วยls-output.txt2>

ฉันคิดว่าคนที่พูดว่าstderrควรใช้เฉพาะกับข้อความผิดพลาดนั้นทำให้เข้าใจผิด

ควรใช้สำหรับข้อความที่ให้ข้อมูลสำหรับผู้ใช้ที่รันคำสั่งไม่ใช่สำหรับผู้ใช้ดาวน์สตรีมของข้อมูล (เช่นถ้าคุณรันเชลล์ไพพ์การโยงหลายคำสั่งคุณไม่ต้องการข้อความที่ให้ข้อมูลเช่น "การรับไอเท็ม 30 42424 "ปรากฏบนstdoutเนื่องจากพวกเขาจะสร้างความสับสนให้ผู้บริโภค แต่คุณอาจต้องการให้ผู้ใช้เห็นพวกเขา

ดูสิ่งนี้สำหรับเหตุผลทางประวัติศาสตร์:

"โปรแกรมทั้งหมดวางการวินิจฉัยบนเอาต์พุตมาตรฐานซึ่งมักทำให้เกิดปัญหาเมื่อเอาต์พุตถูกเปลี่ยนเส้นทางไปยังไฟล์ แต่กลายเป็นปัญหามากเกินไปเมื่อเอาต์พุตถูกส่งไปยังกระบวนการที่ไม่สงสัยอย่างไรก็ตามไม่ต้องการละเมิดความเรียบง่ายของอินพุตมาตรฐาน - ผู้คนยอมรับสถานการณ์นี้ผ่าน v6 หลังจากนั้นไม่นาน Dennis Ritchie ได้ตัดปม Gordian ด้วยการแนะนำข้อผิดพลาดมาตรฐานที่ยังไม่เพียงพอด้วยการวินิจฉัยระบบท่ออาจมาจากหลาย ๆ โปรแกรมที่ทำงานพร้อมกัน เพื่อระบุตัวเอง "

การใช้ ps -aux เผยให้เห็นกระบวนการปัจจุบันทั้งหมดที่ระบุไว้ใน / proc / as / proc / (pid) / โดยการเรียก cat / proc / (pid) / fd / 0 มันพิมพ์สิ่งที่พบในการส่งออกมาตรฐานของ ฉันคิดว่ากระบวนการนั้น ดังนั้นบางที

/ proc / (pid) / fd / 0 - ไฟล์เอาต์พุตมาตรฐาน
/ proc / (pid) / fd / 1 - ไฟล์อินพุตมาตรฐาน
/ proc / (pid) / fd / 2 - ไฟล์ข้อผิดพลาดมาตรฐาน

ตัวอย่างเช่น

แต่ทำงานได้ดีสำหรับ / bin / bash กระบวนการอื่น ๆ โดยทั่วไปไม่มีอะไรใน 0 แต่หลายคนมีข้อผิดพลาดที่เขียนใน 2

สำหรับข้อมูลที่เชื่อถือได้เกี่ยวกับไฟล์เหล่านี้ให้ตรวจสอบ man pages, รันคำสั่งบนเทอร์มินัลของคุณ

$ man stdout 

แต่สำหรับคำตอบง่ายๆแต่ละไฟล์มีไว้สำหรับ:

stdoutสำหรับสตรีมออกมา

stdinสำหรับอินพุตสตรีม

stderrสำหรับการพิมพ์ข้อผิดพลาดหรือบันทึกข้อความ

แต่ละโปรแกรมยูนิกซ์มีหนึ่งในสตรีมเหล่านั้น

stderr จะไม่ทำบัฟเฟอร์ IO Cache ดังนั้นหากแอปพลิเคชันของเราจำเป็นต้องพิมพ์ข้อมูลข้อความสำคัญ (ข้อผิดพลาดข้อยกเว้นบางอย่าง) เพื่อคอนโซลหรือไฟล์ใช้มันในกรณีที่ใช้ stdout เพื่อพิมพ์ข้อมูลบันทึกทั่วไปที่ใช้ IO Cache บัฟเฟอร์มีโอกาสที่ ก่อนที่จะเขียนข้อความของเราไปยังแอปพลิเคชันไฟล์อาจปิดทำให้การดีบักซับซ้อน

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

https://www.mkssoftware.com/docs/man5/stdio.5.asp