ทำไม / dev / null ไฟล์? ทำไมฟังก์ชั่นการใช้งานไม่ได้เป็นโปรแกรมอย่างง่าย?

ฉันพยายามเข้าใจแนวคิดของไฟล์พิเศษบน Linux อย่างไรก็ตามมีไฟล์พิเศษใน/devดูเหมือนโง่ธรรมดาเมื่อฟังก์ชั่นสามารถนำมาใช้โดยไม่กี่บรรทัดใน C เพื่อความรู้ของฉัน

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

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

# We don't care about log output.
$ frobify --log-file=/dev/null

# We are not interested in the compiled binary, just seeing if there are errors.
$ gcc foo.c -o /dev/null  || echo "foo.c does not compile!".

# Easy way to force an empty list of exceptions.
$ start_firewall --exception_list=/dev/null

ทั้งหมดนี้เป็นกรณีที่การใช้โปรแกรมเป็นแหล่งหรืออ่างล้างจานจะยุ่งยากอย่างมาก แม้ในกรณีไปป์ไลน์เชลล์ stdout และ stderr อาจถูกเปลี่ยนเส้นทางไปยังไฟล์อย่างอิสระสิ่งที่ยากต่อการทำงานกับ executables เป็น sinks:

# Suppress errors, but print output.
$ grep foo * 2>/dev/null

ในความเป็นธรรมก็ไม่ได้เป็นแฟ้มปกติต่อ se; มันเป็นอุปกรณ์พิเศษของตัวละคร :

$ file /dev/null
/dev/null: character special (3/2)

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

ฉันสงสัยว่าทำไมมีหลายอย่างที่เกี่ยวข้องกับวิสัยทัศน์ / การออกแบบที่มีรูปแบบ Unix (และต่อจาก Linux) และข้อดีที่เกิดขึ้นจากมัน

ไม่ต้องสงสัยเลยว่ามีข้อดีด้านประสิทธิภาพการทำงานที่ไม่อาจละเลยได้ แต่ฉันคิดว่ามีอีกมาก: Unix ยุคแรกมีอุปมา "ทุกอย่างเป็นไฟล์" ซึ่งมีข้อดีที่ไม่ชัดเจน แต่สง่างามถ้าคุณดู จากมุมมองของระบบมากกว่ามุมมองการเขียนสคริปต์เชลล์

สมมติว่าคุณมีnullโปรแกรมบรรทัดคำสั่งและ/dev/nullโหนดอุปกรณ์ จากมุมมองของการเขียนสคริปต์ shell foo | nullโปรแกรมจริงๆแล้วมีประโยชน์และสะดวกมากและfoo >/dev/nullใช้เวลาในการพิมพ์นานกว่าเล็กน้อยและอาจดูแปลก ๆ

แต่นี่คือแบบฝึกหัดสองข้อ:

1. ลองใช้โปรแกรมnullโดยใช้เครื่องมือที่มีอยู่และ Unix /dev/null- cat >/dev/nullง่าย: เสร็จสิ้น

2. คุณสามารถนำไปใช้/dev/nullในแง่ของnull?

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

พิจารณา: ภาษาการเขียนโปรแกรมเกือบทุกภาษาต้องทำงานกับไฟล์ตัวอธิบายไฟล์และพา ธ ไฟล์เนื่องจากเป็นส่วนหนึ่งของกระบวนทัศน์ "ทุกอย่างเป็นไฟล์" ของ Unix ตั้งแต่ต้น

หากสิ่งที่คุณมีคือโปรแกรมที่เขียนไปยัง stdout โปรแกรมไม่สนใจว่าคุณจะเปลี่ยนเส้นทางไปเป็นไฟล์เสมือนที่กลืนกินการเขียนทั้งหมดหรือไพพ์ลงในโปรแกรมที่กลืนการเขียนทั้งหมด

ตอนนี้ถ้าคุณมีโปรแกรมที่ใช้เส้นทางแฟ้มสำหรับการอ่านหรือเขียนข้อมูล (ซึ่งโปรแกรมส่วนใหญ่ทำ) - และคุณต้องการที่จะเพิ่ม "การป้อนข้อมูลว่างเปล่า" หรือ "ทิ้งเอาท์พุทนี้" การทำงานกับโปรแกรมเหล่านั้น - อย่างดีกับ/dev/nullที่มาฟรี

โปรดสังเกตว่าความสง่างามของมันคือการลดความซับซ้อนของรหัสของโปรแกรมที่เกี่ยวข้องทั้งหมด - สำหรับแต่ละ usecase ทั่วไป แต่พิเศษที่ระบบของคุณสามารถให้เป็น "ไฟล์" ด้วย "ชื่อไฟล์" จริงรหัสของคุณสามารถหลีกเลี่ยงการเพิ่มคำสั่งที่กำหนดเอง ตัวเลือกบรรทัดและเส้นทางรหัสที่กำหนดเองเพื่อจัดการ

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

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

ยูนิกซ์ประสบความสำเร็จมากเท่าที่ทำได้เนื่องจากบางส่วนของนามธรรมเหล่านี้ทำงานร่วมกัน/dev/nullได้ดีและเข้าใจได้ดีที่สุดในฐานะส่วนหนึ่งของทั้งหมด

ป.ล. มันน่าดูรุ่น Unix ของ "ทุกอย่างเป็นไฟล์" และสิ่งต่าง ๆ เช่น/dev/nullขั้นตอนแรกสู่การวางตัวแบบทั่วไปที่มีความยืดหยุ่นและทรงพลังของอุปมาอุปมัยที่ถูกนำไปใช้ในหลาย ๆ ระบบที่ตามมา

ตัวอย่างเช่นในวัตถุที่คล้ายไฟล์พิเศษของ Unix อย่างเช่น/dev/nullจะต้องมีการใช้งานในเคอร์เนลเอง แต่ปรากฎว่ามันมีประโยชน์พอที่จะเปิดเผยการทำงานในรูปแบบไฟล์ / โฟลเดอร์ที่ตั้งแต่นั้นมามีหลายระบบที่ทำวิธีสำหรับโปรแกรม ทำเช่นนั้น

หนึ่งในคนแรกคือระบบปฏิบัติการแผน 9 ทำโดยคนเดียวกันบางคนที่ทำยูนิกซ์ ต่อมา GNU Hurd ก็ทำสิ่งที่คล้ายกับ "นักแปล" ของมัน ในขณะเดียวกันลีนุกซ์ก็ได้รับ FUSE (ซึ่งแพร่กระจายไปยังระบบกระแสหลักอื่น ๆ ในตอนนี้เช่นกัน)

ผมคิดว่า/dev/nullเป็นอุปกรณ์ตัว (ว่าพฤติกรรมเช่นไฟล์สามัญ) แทน programm สำหรับเหตุผลประสิทธิภาพ

ถ้ามันจะเป็นโปรแกรมมันจะต้องมีการโหลดเริ่มต้นการตั้งเวลาการทำงานและหลังจากนั้นหยุดและขนถ่ายโปรแกรม โปรแกรม C แบบง่าย ๆ ที่คุณกำลังอธิบายจะไม่กิน ressources มากมาย แต่ฉันคิดว่ามันสร้างความแตกต่างที่สำคัญเมื่อพิจารณาจำนวนมาก (พูดนับล้าน) ของการดำเนินการเปลี่ยนเส้นทาง / การวางท่อเนื่องจากการดำเนินการจัดการกระบวนการมีราคาสูง พวกเขาเกี่ยวข้องกับการสลับบริบท

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

นอกเหนือจาก "ทุกอย่างเป็นไฟล์" และความสะดวกในการใช้งานในทุกที่ที่คำตอบอื่น ๆ ส่วนใหญ่อ้างอิงจากนั้นยังมีปัญหาด้านประสิทธิภาพตามที่ @ user5626466 กล่าวถึง

เพื่อแสดงในทางปฏิบัติเราจะสร้างโปรแกรมอย่างง่ายที่เรียกว่าnullread.c:

#include <unistd.h>
char buf[1024*1024];
int main() {
        while (read(0, buf, sizeof(buf)) > 0);
}

และรวบรวมมันด้วย gcc -O2 -Wall -W nullread.c -o nullread

(หมายเหตุ: เราไม่สามารถใช้ lseek (2) กับท่อดังนั้นวิธีเดียวที่จะระบายท่อคือการอ่านจากมันจนกว่ามันจะว่างเปล่า)

% time dd if=/dev/zero bs=1M count=5000 |  ./nullread
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 9,33127 s, 562 MB/s
dd if=/dev/zero bs=1M count=5000  0,06s user 5,66s system 61% cpu 9,340 total
./nullread  0,02s user 3,90s system 41% cpu 9,337 total

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

% time dd if=/dev/zero bs=1M count=5000 > /dev/null
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,08947 s, 4,8 GB/s
dd if=/dev/zero bs=1M count=5000 > /dev/null  0,01s user 1,08s system 99% cpu 1,094 total

(นี่ควรเป็นความคิดเห็นที่นั่น แต่ใหญ่เกินไปสำหรับสิ่งนั้นและไม่สามารถอ่านได้อย่างสมบูรณ์)

คำถามของคุณถูกวางตัวราวกับว่าบางสิ่งอาจจะได้มาจากความเรียบง่ายโดยใช้โปรแกรม null แทนไฟล์ บางทีเราสามารถกำจัดความคิดของ "ไฟล์มายากล" และแทนที่จะมี "ท่อธรรมดา" แทน

แต่พิจารณาว่าไปป์นั้นเป็นไฟล์ด้วย โดยปกติแล้วพวกเขาจะไม่ตั้งชื่อและสามารถจัดการผ่านตัวอธิบายไฟล์เท่านั้น

ลองพิจารณาตัวอย่างที่ประดิษฐ์ขึ้นนี้:

$ echo -e 'foo\nbar\nbaz' | grep foo
foo

การใช้การทดแทนกระบวนการของ Bash ทำให้เราสามารถทำสิ่งเดียวกันให้สำเร็จผ่านทางวงเวียนที่มากขึ้น:

$ grep foo <(echo -e 'foo\nbar\nbaz')
foo

แทนที่grepสำหรับechoและเราสามารถเห็นภายใต้ฝาครอบ:

$ echo foo <(echo -e 'foo\nbar\nbaz')
foo /dev/fd/63

<(...)สร้างเป็นเพียงการแทนที่ด้วยชื่อไฟล์และ grep คิดว่ามันเปิดไฟล์เก่า ๆ /dev/fd/63มันก็เกิดขึ้นที่จะมีชื่อ นี่/dev/fdคือไดเรกทอรีมายากลที่ทำให้ชื่อ pipes สำหรับทุกไฟล์อธิบายที่ครอบครองโดยไฟล์ที่เข้าถึงมัน

เราสามารถทำให้เวทมนต์น้อยลงด้วยmkfifoการสร้างไปป์ที่มีชื่อที่ปรากฏขึ้นlsและทุกอย่างเหมือนไฟล์ทั่วไป:

$ mkfifo foofifo
$ ls -l foofifo 
prw-rw-r-- 1 indigo indigo 0 Apr 19 22:01 foofifo
$ grep foo foofifo

อื่น ๆ :

$ echo -e 'foo\nbar\nbaz' > foofifo

และดูเถิด grep fooออกจะ

ผมคิดว่าเมื่อคุณตระหนักท่อและไฟล์ปกติและไฟล์พิเศษเช่น / dev / null มีไฟล์ทั้งหมดเพียงแค่นี้ก็เห็นได้ชัดการใช้โปรแกรม null เป็นมากขึ้นซับซ้อน เคอร์เนลต้องจัดการกับการเขียนไปยังไฟล์ด้วยวิธีใดวิธีหนึ่ง แต่ในกรณีของ / dev / null มันสามารถปล่อยการเขียนลงบนพื้นได้ในขณะที่ไพพ์จะต้องถ่ายโอนไบต์ไปยังโปรแกรมอื่นซึ่งจากนั้นจะต้อง อ่านจริง ๆ พวกเขา

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

ดังที่คนอื่น ๆ ชี้ไปแล้ว/dev/null คือโปรแกรมที่ทำจากโค้ดจำนวนหนึ่ง เป็นเพียงแค่บรรทัดโค้ดเหล่านี้เป็นส่วนหนึ่งของเคอร์เนล

เพื่อให้ชัดเจนยิ่งขึ้นนี่คือการใช้งาน Linux: อุปกรณ์ตัวอักษรเรียกฟังก์ชันเมื่ออ่านหรือเขียน การเขียนไปยัง/dev/nullโทรwrite_nullในขณะที่อ่านโทรread_nullลงทะเบียนที่นี่

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

ฉันหวังว่าคุณจะตระหนักถึง / dev / chargen / dev / zero และอื่น ๆ เช่นพวกเขารวมถึง / dev / null

LINUX / UNIX มีคุณสมบัติเหล่านี้บางส่วน - ทำให้ผู้ใช้สามารถใช้ WELL WRITTEN CODE FragMEnTS ได้ดี

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

ศูนย์ถูกออกแบบมาเพื่อเติมไฟล์ที่มีอยู่หรือส่งออกจำนวนมากทั้งศูนย์

/ dev / null เป็นเพียงเครื่องมืออื่นที่มีแนวคิดเดียวกันในใจ

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

ให้ตั้งค่าการแข่งขันเพื่อดูว่าใครสามารถสร้างผลลัพธ์ที่น่าตื่นเต้นที่สุดให้กับอุปกรณ์ตัวละครเพียงไม่กี่ตัวในรุ่น LINUX ของคุณ