ฉันควรใช้วงเล็บมุมเดี่ยวหรือคู่เพื่อเปลี่ยนเส้นทางไปยัง / dev / null หรือไม่


18

คำตอบส่วนใหญ่ที่นี่[ 1 ] [ 2 ] [ 3 ]ใช้วงเล็บมุมเดียวเพื่อเปลี่ยนเส้นทางไปยัง / dev / null เช่นนี้

command > /dev/null

แต่การผนวกกับ / dev / null ก็ใช้งานได้เช่นกัน:

command >> /dev/null

ยกเว้นตัวละครพิเศษมีเหตุผลอะไรที่จะไม่ทำเช่นนี้? เป็น "nicer" เหล่านี้อย่างใดอย่างหนึ่งเพื่อการใช้งานพื้นฐานของ / dev / null?

แก้ไข: เปิด (2) manpageกล่าวlseekเรียกว่าก่อนที่จะเขียนไฟล์ในโหมดผนวก:

O_APPEND
ไฟล์ถูกเปิดในโหมดต่อท้าย ก่อนการเขียนแต่ละครั้ง (2) ไฟล์ออฟเซ็ตจะอยู่ที่ท้ายไฟล์เช่นเดียวกับ lseek (2) การแก้ไขไฟล์ออฟเซ็ตและการดำเนินการเขียนจะดำเนินการในขั้นตอนเดียวของอะตอมมิก

ซึ่งทำให้ฉันคิดว่าอาจจะมีการลงโทษประสิทธิภาพเล็ก ๆ >>สำหรับการใช้ แต่ในทางกลับกันการตัดทอน / dev / null ดูเหมือนว่าเป็นการดำเนินการที่ไม่ได้กำหนดตามเอกสารนั้น:

O_TRUNC
หากไฟล์มีอยู่แล้วและเป็นไฟล์ปกติและโหมดการเข้าถึงอนุญาตให้เขียน (เช่นคือ O_RDWR หรือ O_WRONLY) ไฟล์นั้นจะถูกตัดทอนเป็นความยาว 0 หากไฟล์นั้นเป็นไฟล์ FIFO หรือเทอร์มินัลแฟล็ก O_TRUNC จะถูกละเว้น มิฉะนั้นเอฟเฟกต์ของ O_TRUNC จะไม่ได้รับการระบุ

และข้อมูลจำเพาะ POSIX บอกว่า>จะตัดทอนไฟล์ที่มีอยู่แต่O_TRUNC ถูกกำหนดให้ใช้งานสำหรับไฟล์อุปกรณ์และไม่มีคำตอบว่า / dev / null ควรตอบสนองต่อการถูกตัดทอนอย่างไร

ดังนั้นการตัดทอน / dev / null จึงไม่ได้ระบุจริงหรือ และการเรียกlseekมีผลกระทบต่อประสิทธิภาพการเขียนหรือไม่?

คำตอบ:


27

ตามคำนิยามจะ/dev/nullจมสิ่งที่เขียนลงไปดังนั้นจึงไม่สำคัญว่าคุณจะเขียนในโหมดต่อท้ายหรือไม่มันก็ถูกทิ้งทั้งหมด เนื่องจากมันไม่ได้เก็บข้อมูลจึงไม่มีสิ่งใดที่จะผนวกเข้าด้วยกันจริงๆ

ดังนั้นในที่สุดมันสั้นกว่าที่จะเขียน> /dev/nullด้วย>เครื่องหมายเดียว

สำหรับส่วนเพิ่มเติมที่แก้ไข:

manpage เปิด (2) บอกว่า lseek ถูกเรียกก่อนการเขียนแต่ละไฟล์ในโหมดต่อท้าย

หากคุณอ่านอย่างใกล้ชิดคุณจะเห็นข้อความบอกว่า (เน้นที่เหมือง):

ไฟล์ออฟเซตถูกวางตำแหน่งที่ท้ายไฟล์ราวกับว่ามี lseek (2)

ความหมายมันไม่จำเป็นต้องเรียกการเรียกของlseekระบบและผลไม่เหมือนกันอย่างแน่นอน: การโทรที่lseek(fd, SEEK_END, 0); write(fd, buf, size);ไม่มีO_APPENDไม่เหมือนกับการเขียนในโหมดผนวกเนื่องจากการโทรแยกกันกระบวนการอื่นสามารถเขียนลงใน ไฟล์ในระหว่างการโทรของระบบการทำลายข้อมูลที่ผนวก ในโหมดต่อท้ายสิ่งนี้จะไม่เกิดขึ้น (ยกเว้นNFS ซึ่งไม่สนับสนุนโหมดผนวกจริง )

ข้อความในมาตรฐานไม่ได้พูดถึงlseekที่จุดนั้นเพียง แต่ที่เขียนจะไปสิ้นสุดของแฟ้ม

ดังนั้นการตัดทอน / dev / null จึงไม่มีการระบุจริงหรือไม่

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

และการเรียก lseek มีผลกระทบต่อประสิทธิภาพการเขียนหรือไม่?

ทดสอบมัน เป็นวิธีเดียวที่จะทราบได้อย่างแน่นอนในระบบที่กำหนด หรืออ่านแหล่งข้อมูลเพื่อดูว่าโหมดต่อท้ายจะเปลี่ยนลักษณะการทำงานอย่างไรที่ใดก็ได้


-3

ถ้าเป็นประสิทธิภาพที่คุณต้องการให้ใช้command >&-แทน นี่เป็นการปิดตัวอธิบายไฟล์แทนที่จะเปลี่ยนเส้นทางดังนั้นจึงไม่มีเวลาที่จะเขียนสิ่งต่าง ๆ ลงไปเลย


3
อย่าปิดสตรีมที่มีค่าน้อยกว่า 3 ซึ่งจะใช้นามแฝงตัวอธิบาย std * พร้อมตัวอธิบายไฟล์แบบสุ่ม อาจมีผลเป็นความหายนะ
Joshua

7
หากคุณเพียงแค่ปิดไฟล์ descriptor โปรแกรมจะได้รับข้อผิดพลาดในการเรียกการเขียนทุกครั้งซึ่งอาจนำไปสู่ข้อความแสดงข้อผิดพลาดที่น่ารำคาญ
ilkkachu
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.