मैं कर सकता हूँ cat /dev, मैं कर सकता हूँ ls /dev, मैं नहीं कर सकता less /dev। catमुझे catइस निर्देशिका को क्यों करने देता है लेकिन कोई अन्य निर्देशिका नहीं है?
मैं कर सकता हूँ cat /dev, मैं कर सकता हूँ ls /dev, मैं नहीं कर सकता less /dev। catमुझे catइस निर्देशिका को क्यों करने देता है लेकिन कोई अन्य निर्देशिका नहीं है?
जवाबों:
ऐतिहासिक रूप से (V7 UNIX तक, या 1979 के आसपास) readसिस्टम कॉल ने फाइलों और निर्देशिकाओं दोनों पर काम किया। readएक निर्देशिका में एक साधारण डेटा संरचना होगी जो एक उपयोगकर्ता प्रोग्राम निर्देशिका प्रविष्टियों को प्राप्त करने के लिए पार्स करेगा। वास्तव में, V7 lsटूल ने ठीक यही किया - readएक निर्देशिका पर, परिणामस्वरूप डेटा संरचना को पार्स, एक संरचित सूची प्रारूप में आउटपुट।
चूंकि फाइलसिस्टम अधिक जटिल थे, इसलिए इस "सरल" डेटा संरचना को अधिक जटिल मिला, उस बिंदु पर जहां एक readdirपुस्तकालय फ़ंक्शन को कार्यक्रमों को आउटपुट के पार्स करने में मदद करने के लिए जोड़ा गया था read(directory)। विभिन्न प्रणालियों और फाइल सिस्टम में अलग-अलग डिस्क प्रारूप हो सकते हैं, जो जटिल हो रहे थे।
जब सन ने नेटवर्क फाइल सिस्टम (एनएफएस) की शुरुआत की, तो वे ऑन-डिस्क निर्देशिका संरचना को पूरी तरह से अलग करना चाहते थे। read(directory)हालांकि, अपनी वापसी को निर्देशिका का एक प्लेटफ़ॉर्म-स्वतंत्र प्रतिनिधित्व बनाने के बजाय , उन्होंने एक नया सिस्टम कॉल जोड़ा getdirents- और readनेटवर्क-माउंटेड निर्देशिकाओं पर प्रतिबंध लगा दिया । यह सिस्टम कॉल तेजी से विभिन्न UNIX जायके में सभी निर्देशिकाओं पर काम करने के लिए अनुकूलित किया गया था, जिससे यह निर्देशिकाओं की सामग्री प्राप्त करने का डिफ़ॉल्ट तरीका है। (इतिहास https://utcc.utoronto.ca/~cks/space/blog/unix/ReaddrHistory से सारगर्भित )
क्योंकि readdirअब निर्देशिकाओं को पढ़ने का डिफ़ॉल्ट तरीका है, read(directory)आमतौर पर लागू नहीं किया जाता है (रिटर्न -EISDIR) अधिकांश आधुनिक OSes (QNX), उदाहरण के लिए, एक उल्लेखनीय अपवाद है जो कि लागू होता readdirहै read(directory))। हालांकि, अधिकांश आधुनिक कर्नेल में "वर्चुअल फाइल सिस्टम" डिजाइन के साथ, यह वास्तव में व्यक्तिगत फाइल सिस्टम पर निर्भर है कि निर्देशिका काम करती है या नहीं।
और वास्तव में, macOS पर, माउंटपॉइंट पर devfsअंतर्निहित फाइल सिस्टम /devवास्तव में रीडिंग का समर्थन करता है ( https://github.com/apple/darwin-xnu/blob/xnu-4570.1.46/bsd/miscfs/devfs_devfs_vnops.c#L629 ) :
static int
devfs_read(struct vnop_read_args *ap)
{
devnode_t * dn_p = VTODN(ap->a_vp);
switch (ap->a_vp->v_type) {
case VDIR: {
dn_p->dn_access = 1;
return VNOP_READDIR(ap->a_vp, ap->a_uio, 0, NULL, NULL, ap->a_context);
READDIRयदि आप पढ़ने की कोशिश करते हैं तो यह स्पष्ट रूप से कॉल करता है /dev(नीचे फ़ाइलों को पढ़ना /devएक अलग फ़ंक्शन द्वारा नियंत्रित किया जाता है - devfsspec_read)। इसलिए, यदि कोई प्रोग्राम readसिस्टम को कॉल करता है /dev, तो वह सफल होगा और डायरेक्टरी लिस्टिंग प्राप्त करेगा!
यह प्रभावी रूप से एक ऐसी सुविधा है जो UNIX के शुरुआती दिनों से एक होल्डओवर है, और जिसे बहुत लंबे समय में नहीं छुआ गया है। मेरे हिस्से को संदेह है कि यह कुछ पीछे संगतता संगतता कारण के लिए रखा जा रहा है, लेकिन यह बस इतनी आसानी से हो सकता है कि कोई भी इस सुविधा को हटाने के लिए पर्याप्त परवाह नहीं करता है क्योंकि यह वास्तव में कुछ भी चोट नहीं पहुंचा रहा है।
कम एक पाठ फ़ाइल दर्शक है, बिल्ली मनमाना डेटा कॉपी करने के लिए एक उपकरण है। इसलिए कम यह सुनिश्चित करने के लिए अपनी स्वयं की जाँच करता है कि आप कुछ ऐसा नहीं खोल रहे हैं जिसमें भारी मात्रा में डेटा होगा या बहुत अजीब तरीके से व्यवहार करेगा। दूसरी ओर, बिल्ली के पास ऐसी कोई जाँच नहीं है - यदि कर्नेल आपको कुछ खोलने देता है (भले ही यह एक पाइप या डिवाइस या कुछ और भी खराब हो), बिल्ली इसे पढ़ेगी।
तो ओएस क्यों बिल्ली को निर्देशिकाओं को खोलने की अनुमति देता है ? परंपरागत रूप से बीएसडी-शैली प्रणालियों में सभी निर्देशिकाओं को फ़ाइलों के रूप में पढ़ा जा सकता है, और यह था कि कैसे प्रोग्राम पहली जगह में एक निर्देशिका की सूची देगा: डिस्क पर संग्रहीत महंगे संरचनाओं की व्याख्या करके।
बाद में, उन ऑन-डिस्क संरचनाओं को कर्नेल द्वारा उपयोग किए जाने वाले डिरेंट से विचलन करना शुरू हुआ: जहां पहले एक निर्देशिका एक रैखिक सूची थी, बाद में फाइलसिस्टम ने हैशटेबल्स, बी-ट्रीज़, और इसी तरह का उपयोग करना शुरू कर दिया। तो निर्देशिकाओं को सीधे पढ़ना अब और सरल नहीं था - कर्नेल ने इसके लिए समर्पित कार्यों को बढ़ाया। (मुझे यकीन नहीं है कि अगर यह मुख्य कारण था, या यदि उन्हें मुख्य रूप से अन्य कारणों जैसे कैशिंग के लिए जोड़ा गया है।)
कुछ बीएसडी सिस्टम आपको पढ़ने के लिए सभी निर्देशिकाओं को खोलने देते हैं; मुझे नहीं पता कि वे आपको डिस्क से कच्चा डेटा देते हैं, या क्या वे इसके बजाय एक अनुकरणीय सूची को वापस करते हैं, या वे फाइलसिस्टम ड्राइवर को तय करने देते हैं।
तो शायद macOS उन ऑपरेटिंग सिस्टमों में से एक है जहाँ कर्नेल इसे तब तक अनुमति देता है जब तक फाइल सिस्टम डेटा प्रदान करता है। और अंतर यह है कि /devएक devfsफाइलसिस्टम पर है जिसे शुरुआती दिनों में इसे अनुमति देने के लिए लिखा गया था, जबकि /एक एपीएफएस फाइलसिस्टम पर है जिसने इस सुविधा को आधुनिक समय में अनावश्यक रूप से छोड़ दिया है।
अस्वीकरण: मैंने वास्तव में बीएसडी या मैकओएस पर कोई शोध नहीं किया है। मैं बस इसे पंख लगा रहा हूं।
/etc, इसलिए मैंने अपने बेंचमार्क के रूप में इसका इस्तेमाल किया।
mountया /sbin/mountदेखने के लिए वर्तमान में जहां घुड़सवार है।
/devएक आभासी फ़ाइल का उपयोग कर प्रणाली है devfsचालक जबकि /etcका हिस्सा है /का उपयोग कर फाइल सिस्टम apfsड्राइवर। तो कारण catएक को पढ़ेगा और दूसरे को ड्राइवरों apfsऔर devfsड्राइवरों के बीच अंतर नहीं करेगा ।
neofetchआपकी जानकारी के लिए है :) i.imgur.com/3azpnDt.png