"सब कुछ एक फ़ाइल है" थोड़ा ग्लिब है। "सब कुछ फाइलसिस्टम में कहीं न कहीं दिखाई देता है " निशान के करीब है, और फिर भी, यह सिस्टम डिजाइन के एक नियम की तुलना में अधिक आदर्श है।
उदाहरण के लिए, यूनिक्स डोमेन सॉकेट फाइलें नहीं हैं, लेकिन वे फाइल सिस्टम में दिखाई देते हैं। आप ls -lएक डोमेन सॉकेट को उसकी विशेषताओं, catडेटा को / से प्रदर्शित करने, उसके एक्सेस कंट्रोल को संशोधित करने chmodआदि के लिए कर सकते हैं।
लेकिन, भले ही नियमित टीसीपी / आईपी नेटवर्क सॉकेट बनाए जाते हैं और एक ही बीएसडी सॉकेट सिस्टम कॉल के साथ हेरफेर किया जाता है, क्योंकि यूनिक्स डोमेन सॉकेट्स, टीसीपी / आईपी सॉकेट्स फाइलसिस्टम में नहीं दिखाते हैं, ¹ भले ही कोई विशेष रूप से अच्छा कारण नहीं है - यह होना चाहिए सच हो।
फ़ाइल सिस्टम में दिखाई देने वाली गैर-फ़ाइल ऑब्जेक्ट का एक और उदाहरण लिनक्स का /procफाइल सिस्टम है । यह सुविधा कर्नेल के रन-टाइम ऑपरेशन के बारे में उपयोगकर्ता के स्थान के बारे में बहुत कुछ बताती है , जो ज्यादातर आभासी सादे पाठ फ़ाइलों के रूप में होती है। कई /procप्रविष्टियां केवल पढ़ने के लिए होती हैं, लेकिन बहुत कुछ /procलेखन योग्य भी होता है, इसलिए आप सिस्टम को किसी भी प्रोग्राम का उपयोग करके चलाने के तरीके को बदल सकते हैं जो किसी फ़ाइल को संशोधित कर सकता है। काश, यहाँ फिर से हमारे पास एक ग़ैर-बराबरी है: बीएसडी प्रकार के यूनिक्स आम तौर पर बिना चलते हैं/proc , और सिस्टम वी यूनिक्स /procभी लिनक्स की तुलना में बहुत कम उजागर करता है।
मैं एमएस विंडोज के साथ इसके विपरीत नहीं कर सकता
सबसे पहले, बहुत सारी भावनाएं आप ऑनलाइन और पुस्तकों में देख सकते हैं, यूनिक्स के बारे में फाइल I / O और विंडोज के बारे में सब कुछ इस संबंध में "टूटा हुआ" अप्रचलित है। विंडोज एनटी ने इसमें बहुत कुछ तय किया।
विंडोज के आधुनिक संस्करणों में यूनिक्स की तरह एक एकीकृत I / O सिस्टम है, इसलिए यदि आप चाहते हैं, तो आप ReadFile()Windows सॉकेट्स विशिष्ट API के बजाय टीसीपी / आईपी सॉकेट से नेटवर्क डेटा पढ़ सकते हैं WSARecv()। यह ठीक समानताएं यूनिक्स रास्ता है, जहां आप या तो सामान्य के साथ एक नेटवर्क सॉकेट से पढ़ सकते हैं read(2)यूनिक्स प्रणाली कॉल या सॉकेट विशेष recv(2)call.²
फिर भी, विंडोज अभी भी इस अवधारणा को यूनिक्स के समान स्तर पर ले जाने में विफल रहता है, यहां तक कि 2018 में भी। विंडोज आर्किटेक्चर के कई क्षेत्र हैं जिन्हें फाइल सिस्टम के माध्यम से एक्सेस नहीं किया जा सकता है, या जिसे फ़ाइल की तरह नहीं देखा जा सकता है। कुछ उदाहरण:
ड्राइवर।
विंडोज का ड्राइवर सबसिस्टम यूनिक्स की तरह आसानी से समृद्ध और शक्तिशाली है, लेकिन ड्राइवरों को हेरफेर करने के लिए प्रोग्राम लिखने के लिए, आपको आमतौर पर विंडोज ड्राइवर किट का उपयोग करना होगा , जिसका अर्थ है सी या .NET कोड लिखना।
यूनिक्स प्रकार के ओएस पर, आप कमांड लाइन से ड्राइवरों के लिए बहुत कुछ कर सकते हैं। आपने लगभग निश्चित रूप से यह पहले ही कर लिया है, यदि केवल अवांछित आउटपुट को रीडायरेक्ट करके /dev/null.³
अंतर-कार्यक्रम संचार।
विंडोज प्रोग्राम एक दूसरे के साथ आसानी से संवाद नहीं करते हैं।
यूनिक्स कमांड लाइन कार्यक्रम पाठ धाराओं और पाइपों के माध्यम से आसानी से संवाद करते हैं। GUI प्रोग्राम अक्सर कमांड लाइन प्रोग्राम्स के शीर्ष पर बनाए जाते हैं या टेक्स्ट कमांड इंटरफ़ेस निर्यात करते हैं, ताकि GUI प्रोग्राम्स के साथ समान सरल टेक्स्ट-आधारित संचार तंत्र काम करें।
रजिस्ट्री।
यूनिक्स के पास विंडोज रजिस्ट्री का कोई सीधा समकक्ष नहीं है। एक ही जानकारी, में इसमें से अधिकांश फाइल सिस्टम के माध्यम से बिखरे हुए है /etc, /procऔर /sys।
अगर आपको यह नहीं दिखता है कि विंडोज रजिस्ट्री में ड्राइवर, पाइप और यूनिक्स का जवाब "सब कुछ एक फाइल है," पर है।
"सब कुछ एक फ़ाइल है" दर्शन यहाँ कैसे फर्क करता है?
मैं ऊपर अपने तीन बिंदुओं पर विस्तार से बताऊंगा।
लंबे उत्तर, भाग 1: ड्राइव बनाम डिवाइस फ़ाइलें
मान लें कि आपका सीएफ कार्ड रीडर E:विंडोज के /dev/sdcतहत और लिनक्स के तहत दिखाई देता है । क्या व्यावहारिक अंतर पड़ता है?
यह सिर्फ एक मामूली वाक्यविन्यास अंतर नहीं है।
लिनक्स पर, मैं शून्य dd if=/dev/zero of=/dev/sdcके /dev/sdcसाथ सामग्री को अधिलेखित करने के लिए कह सकता हूं ।
इस बारे में सोचें कि एक सेकंड के लिए इसका क्या मतलब है। यहां मेरे पास एक सामान्य उपयोगकर्ता अंतरिक्ष कार्यक्रम ( dd(1)) है, जिसे मैंने वर्चुअल डिवाइस ( /dev/zero) से डेटा पढ़ने और /dev/sdcयूनिफाइड फाइलसिस्टम के माध्यम से एक वास्तविक भौतिक डिवाइस ( ) में पढ़ने के लिए लिखा है । ddपता नहीं है कि यह विशेष उपकरणों से लिख रहा है और पढ़ रहा है। यह नियमित फ़ाइलों पर भी काम करेगा, या उपकरणों और फ़ाइलों के मिश्रण पर, जैसा कि हम नीचे देखेंगे।
E:विंडोज पर ड्राइव को शून्य करने का कोई आसान तरीका नहीं है , क्योंकि विंडोज फाइलों और ड्राइव के बीच अंतर करता है, इसलिए आप उन्हें हेरफेर करने के लिए समान कमांड का उपयोग नहीं कर सकते हैं। निकटतम आप प्राप्त कर सकते हैं एक त्वरित प्रारूप विकल्प के बिना डिस्क प्रारूप करना, जो ड्राइव की अधिकांश सामग्री को शून्य करता है , लेकिन फिर इसके ऊपर एक नया फाइल सिस्टम लिखता है। अगर मुझे नया फाइल सिस्टम नहीं चाहिए तो क्या होगा ? क्या होगा अगर मैं वास्तव में डिस्क को शून्य के अलावा कुछ नहीं भरना चाहता हूं?
आइए उदार बनें और कहें कि हम वास्तव में एक नई नई फाइल सिस्टम चाहते हैं E:। विंडोज पर एक कार्यक्रम में ऐसा करने के लिए, मुझे एक विशेष स्वरूपण एपीआई कॉल करना होगा। लिनक्स पर, आपको ओएस के "प्रारूप डिस्क" कार्यक्षमता तक पहुंचने के लिए एक कार्यक्रम लिखने की आवश्यकता नहीं है। आप केवल उस फ़ाइल प्रकार के लिए उपयुक्त उपयोगकर्ता स्थान प्रोग्राम चलाते हैं जिसे आप बनाना चाहते हैं: mkfs.ext4और mkfs.xfs, या आपके पास क्या है। ये प्रोग्राम जो भी फाइल या /devनोड आप पास करते हैं उस पर एक फाइल सिस्टम लिखेंगे ।
क्योंकि mkfsयूनिक्स सिस्टम पर प्रकार के प्रोग्राम उपकरणों और सामान्य फ़ाइलों के बीच कृत्रिम अंतर बनाए बिना फाइलों पर काम करते हैं, इसका मतलब है कि मैं अपने लिनक्स बॉक्स पर एक सामान्य फ़ाइल के अंदर एक ext4 फाइल सिस्टम बना सकता हूं:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
वह वस्तुतः वर्तमान निर्देशिका में 1 MiB डिस्क छवि बनाता है, जिसे कहा जाता है myfs। मैं तब इसे माउंट कर सकता हूं जैसे कि यह कोई अन्य बाहरी फाइल सिस्टम था:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
अब मेरे पास एक एक्स 4 डिस्क छवि है जिसमें एक फ़ाइल my-passwd-entryहै, जिसमें मेरे उपयोगकर्ता की /etc/passwdप्रविष्टि है।
अगर मैं चाहूं, तो मैं उस छवि को अपने CF कार्ड पर ब्लास्ट कर सकता हूं:
$ sudo dd if=myfs of=/dev/sdc1
या, मुझे लगता है कि डिस्क छवि ऊपर पैक कर सकते हैं, तो आप को मेल, और आप का एक माध्यम के लिए इसे लिखने के जाने अपने इस तरह के एक USB मेमोरी स्टिक के रूप में चुनने,:
$ gzip myfs
$ echo "Here's the disk image I promised to send you." |
mutt -a myfs.gz -s "Password file disk image" you@example.com
यह सब लिनक्स पर संभव है क्योंकि फाइलों, फाइल सिस्टम और उपकरणों के बीच कोई कृत्रिम अंतर नहीं है। यूनिक्स सिस्टम पर बहुत सी बातें या तो कर रहे हैं फ़ाइलें, या फाइल सिस्टम के माध्यम से पहुँचा रहे हैं ताकि वे की तरह लग रही फ़ाइलें, या किसी अन्य तरीके से देखने में पर्याप्त रूप से फ़ाइल की तरह है कि वे इस तरह के रूप में व्यवहार किया जा सकता है।
फाइलसिस्टम का विंडोज कॉन्सेप्ट एक हॉजपोज है; यह निर्देशिका, ड्राइव और नेटवर्क संसाधनों के बीच अंतर करता है। तीन अलग-अलग सिंटैक्स हैं, जो सभी विंडोज में एक साथ मिश्रित होते हैं: यूनिक्स-जैसे ..\FOO\BARपथ प्रणाली, ड्राइव अक्षर जैसे C:, और यूएनसी पथ जैसे \\SERVER\PATH\FILE.TXT। ऐसा इसलिए है क्योंकि यह यूनिक्स, सीपी / एम , एमएस-डॉस और लैन मैनेजर के विचारों का एक सुसंगत डिजाइन के बजाय एक अभिवृद्धि है । यही कारण है कि विंडोज फ़ाइल नामों में बहुत सारे अवैध चरित्र हैं ।
यूनिक्स के पास एक यूनिफ़ॉर्म फाइलसिस्टम है, जिसमें सब कुछ एक ही कॉमन स्कीम द्वारा एक्सेस किया गया है। एक लिनक्स बॉक्स पर चल रहे एक कार्यक्रम करने के लिए, वहाँ के बीच कोई अंतर नहीं है कार्यात्मक /etc/passwd, /media/CF_CARD/etc/passwdऔर /mnt/server/etc/passwd। स्थानीय फाइलें, बाहरी मीडिया और नेटवर्क शेयर सभी का एक ही तरह से व्यवहार किया जाता है
विंडोज ऊपर मेरी डिस्क छवि उदाहरण के समान छोर को प्राप्त कर सकता है, लेकिन आपको विशेष रूप से प्रतिभाशाली प्रोग्रामर द्वारा लिखे गए विशेष कार्यक्रमों का उपयोग करना होगा। यही कारण है कि विंडोज पर बहुत सारे "वर्चुअल डीवीडी" प्रकार के कार्यक्रम हैं । एक कोर ओएस फीचर की कमी ने अंतराल को भरने के लिए कार्यक्रमों के लिए एक कृत्रिम बाजार तैयार किया है, जिसका मतलब है कि आपके पास सर्वश्रेष्ठ आभासी डीवीडी प्रकार प्रोग्राम बनाने के लिए प्रतिस्पर्धा करने वाले लोगों का एक समूह है। हमें * ix सिस्टम पर ऐसे कार्यक्रमों की आवश्यकता नहीं है, क्योंकि हम लूप डिवाइस का उपयोग करके आईएसओ डिस्क छवि को माउंट कर सकते हैं ।
वही अन्य उपकरणों के लिए जाता है जैसे डिस्क पोंछने के कार्यक्रम, जिन्हें हमें यूनिक्स सिस्टम पर भी ज़रूरत नहीं है। क्या आपके सीएफ कार्ड की सामग्री केवल शून्य के बजाय बहुत ही तली हुई है? ठीक है, /dev/randomइसके बजाय डेटा स्रोत के रूप में उपयोग करें /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
लिनक्स पर, हम ऐसे पहियों पर लगाम नहीं लगाते हैं क्योंकि मुख्य OS सुविधाएँ न केवल पर्याप्त रूप से काम करती हैं, वे इतनी अच्छी तरह से काम करती हैं कि वे व्यापक रूप से उपयोग की जाती हैं। लिनक्स बॉक्स को बूट करने के लिए एक विशिष्ट योजना में केवल एक उदाहरण के लिए एक आभासी डिस्क छवि शामिल है, जो मैंने ऊपर दिखाए गए तकनीकों का उपयोग करके बनाई है ।⁷
मुझे लगता है यह कहना है कि अगर यूनिक्स शुरू से ही फाइल सिस्टम में एकीकृत किया था टीसीपी / आईपी आई / ओ, हम नहीं होती केवल निष्पक्ष है netcatबनाम socatबनाम Ncatबनाम गंदगी , कारण है जो की एक ही डिजाइन कमजोरी थी कि करने के लिए नेतृत्व डिस्क इमेजिंग और विंडोज पर उपकरण प्रसार मिटा: एक स्वीकार्य ओएस सुविधा का अभाव।nc
लंबे उत्तर, भाग 2: पाइप्स के रूप में वर्चुअल फाइल्स
डॉस में अपनी जड़ों के बावजूद, विंडोज की कभी भी समृद्ध कमांड लाइन परंपरा नहीं रही है।
यह कहना नहीं है कि विंडोज में कमांड लाइन नहीं है , या इसमें कई कमांड लाइन कार्यक्रमों का अभाव है। विंडोज के पास इन दिनों बहुत शक्तिशाली कमांड शेल है, जिसे उचित रूप से पावरशेल कहा जाता है ।
फिर भी, कमांड-लाइन परंपरा की इस कमी के दस्तक-संबंधी प्रभाव हैं। आपको ऐसे उपकरण मिलते हैं, DISKPARTजो विंडोज दुनिया में लगभग अज्ञात हैं, क्योंकि अधिकांश लोग कंप्यूटर प्रबंधन MMC स्नैप-इन के माध्यम से डिस्क विभाजन और ऐसे करते हैं। फिर जब आपको विभाजन के निर्माण की स्क्रिप्टिंग करने की आवश्यकता होती है, तो आप पाते हैं कि DISKPARTवास्तव में किसी अन्य प्रोग्राम द्वारा संचालित होने के लिए नहीं बनाया गया था। हां, आप एक स्क्रिप्ट फ़ाइल में कमांड की एक श्रृंखला लिख सकते हैं और इसे माध्यम से चला सकते हैं DISKPART /S scriptfile, लेकिन यह सब-या-कुछ भी नहीं है। ऐसी स्थिति में आप वास्तव में क्या चाहते हैं, यह GNU कीparted तरह कुछ और है , जो एकल कमांड को स्वीकार करेगा parted /dev/sdb mklabel gpt। यह आपकी स्क्रिप्ट को चरण-दर-चरण के आधार पर त्रुटि से निपटने की अनुमति देता है।
"यह सब कुछ एक फ़ाइल है" के साथ क्या करना है? आसान: पाइप एक प्रकार की कमांड लाइन I / O को "फाइल" में बनाते हैं। पाइप्स यूनिडायरेक्शनल स्ट्रीम हैं , नियमित डिस्क फ़ाइल की तरह यादृच्छिक-अभिगम नहीं है , लेकिन कई मामलों में अंतर बिना किसी परिणाम के होता है। महत्वपूर्ण बात यह है कि आप दो स्वतंत्र रूप से विकसित कार्यक्रमों को संलग्न कर सकते हैं और उन्हें सरल पाठ के माध्यम से संवाद कर सकते हैं। उस लिहाज से, यूनिक्स वे को ध्यान में रखते हुए डिजाइन किए गए कोई भी दो प्रोग्राम संवाद कर सकते हैं।
उन मामलों में जहां आपको वास्तव में एक फ़ाइल की आवश्यकता होती है, प्रोग्राम आउटपुट को फ़ाइल में बदलना आसान है:
$ some-program --some --args > myfile
$ vi myfile
लेकिन आउटपुट को एक अस्थायी फ़ाइल पर क्यों लिखें जब "सब कुछ एक फ़ाइल है" दर्शन आपको एक बेहतर तरीका देता है? यदि आप सभी करना चाहते हैं, तो उस कमांड के आउटपुट को एक viसंपादक बफर में पढ़ा जाता है , viऐसा आप सीधे कर सकते हैं। से vi"सामान्य" मोड, कहते हैं:
:r !some-program --some --args
यह वर्तमान कर्सर स्थिति में सक्रिय संपादक बफर में उस प्रोग्राम के आउटपुट को सम्मिलित करता है। हुड के तहत, viप्रोग्राम के आउटपुट को बिट कोड से कनेक्ट करने के लिए पाइप का उपयोग कर रहा है जो उसी ओएस कॉल का उपयोग करता है जो इसके बजाय एक फ़ाइल से पढ़ने के लिए उपयोग करेगा। मुझे आश्चर्य नहीं होगा अगर दो मामलों :r- यानी, के साथ और बिना !- दोनों ने सभी सामान्य कार्यान्वयन में एक ही सामान्य डेटा रीडिंग लूप का उपयोग किया vi। मैं नहीं करने के लिए एक अच्छा कारण के बारे में सोच भी नहीं सकते।
यह हाल की विशेषता नहीं है vi, या तो; यह प्राचीन ed(1)पाठ संपादक पर वापस जाता है ।⁸
यह शक्तिशाली विचार यूनिक्स में बार-बार आता है।
इसके दूसरे उदाहरण के लिए, muttऊपर मेरी ईमेल कमांड को याद करें । मुझे लिखने का एकमात्र कारण यह था कि दो अलग-अलग कमांडों के रूप में, मैं चाहता था कि अस्थायी फ़ाइल का नाम दिया *.gzजाए, ताकि ईमेल अटैचमेंट को सही नाम दिया जा सके। अगर मुझे फ़ाइल के नाम की परवाह नहीं है, तो मैं अस्थायी फ़ाइल बनाने से बचने के लिए प्रक्रिया प्रतिस्थापन का उपयोग कर सकता था :
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
यह gzip -cFIFO (जो फ़ाइल की तरह है) या एक /dev/fdऑब्जेक्ट (जो फ़ाइल की तरह है) के आउटपुट को बदलकर अस्थायी से बचा जाता है । (बैश सिस्टम की क्षमताओं के आधार पर विधि का चयन करता है, क्योंकि /dev/fdहर जगह उपलब्ध नहीं है।)
अभी तक एक तीसरा तरीका यह शक्तिशाली विचार यूनिक्स में दिखाई देता है, gdbलिनक्स सिस्टम पर विचार करें । यह C और C ++ में लिखे किसी भी सॉफ्टवेयर के लिए उपयोग किया जाने वाला डिबगर है। अन्य प्रणालियों से यूनिक्स में आने वाले प्रोग्रामर इस gdbबारे में लगभग पूरी तरह से देखते हैं और कहते हैं, "हाँ, यह बहुत आदिम है!" फिर वे जीयूआई डिबगर की खोज करते हैं, जो मौजूद हैं उनमें से एक को ढूंढते हैं, और खुशी से अपना काम जारी रखते हैं ... अक्सर यह कभी नहीं महसूस करते हैं कि जीयूआई केवल gdbनीचे चलता है, इसके शीर्ष पर एक सुंदर खोल प्रदान करता है। अधिकांश यूनिक्स प्रणालियों पर निम्न-स्तरीय डिबगर्स की प्रतिस्पर्धा नहीं है क्योंकि उस स्तर पर प्रतिस्पर्धा करने के लिए कार्यक्रमों की कोई आवश्यकता नहीं है। हमें केवल एक अच्छा निम्न-स्तरीय उपकरण चाहिए, जिसे हम अपने उच्च-स्तरीय उपकरण को आधार बना सकते हैं, यदि वह निम्न-स्तरीय उपकरण पाइप के माध्यम से आसानी से संचार करता है।
इसका मतलब है कि अब हमारे पास एक प्रलेखित डीबगर इंटरफ़ेस है, जो ड्रॉप-इन के प्रतिस्थापन की अनुमति देगा gdb, लेकिन दुर्भाग्य से, प्राथमिक प्रतियोगी gdb कम-घर्षण पथ को नहीं लेगा ।
फिर भी, यह कम से कम संभव है कि कुछ भविष्य के gdbप्रतिस्थापन पारदर्शी रूप से बस अपने कमांड लाइन इंटरफ़ेस को क्लोन करके गिरेंगे। एक ही चीज़ को विंडोज बॉक्स पर खींचने के लिए, बदले जाने योग्य टूल के रचनाकारों को किसी प्रकार के औपचारिक प्लगइन या स्वचालन एपीआई को परिभाषित करना होगा। इसका मतलब है कि यह बहुत लोकप्रिय कार्यक्रमों को छोड़कर नहीं होता है, क्योंकि यह एक सामान्य कमांड लाइन उपयोगकर्ता इंटरफ़ेस और पूर्ण प्रोग्रामिंग एपीआई दोनों का निर्माण करने के लिए बहुत काम है।
यह जादू व्यापक पाठ आधारित आईपीसी की कृपा से होता है ।
यद्यपि विंडोज के कर्नेल में यूनिक्स-शैली के अनाम पाइप हैं , यह सामान्य उपयोगकर्ता प्रोग्रामों को कमांड शेल के बाहर आईपीसी के लिए उपयोग करने के लिए दुर्लभ है , क्योंकि विंडोज में पहले कमांड लाइन संस्करण में सभी कोर सेवाओं को बनाने की इस परंपरा का अभाव है, फिर GUI का निर्माण करना इसके ऊपर अलग से। यह GUI के बिना कुछ चीजें करने में असमर्थ होने का कारण बनता है, जो एक कारण है कि लिनक्स के लिए विंडोज की तुलना में बहुत सारे दूरस्थ डेस्कटॉप सिस्टम हैं , जैसे कि GUI के बिना विंडोज का उपयोग करना बहुत कठिन है।
इसके विपरीत, SSH के माध्यम से दूरस्थ रूप से Unix, BSD, OS X, और Linux बक्से को दूरस्थ रूप से प्रबंधित करना आम है। और यह कैसे काम करता है, आप पूछते हैं? SSH एक के लिए एक नेटवर्क सॉकेट (जो फ़ाइल की तरह) से जोड़ता है छद्म tty में /dev/pty*(जो फ़ाइल की तरह है)। अब आपका रिमोट सिस्टम आपके स्थानीय से एक कनेक्शन के माध्यम से जुड़ा हुआ है, जो कि यूनीक्स वे से इतनी आसानी से मेल खाता है कि यदि आपको ज़रूरत है तो आप SSH कनेक्शन के माध्यम से डेटा को पाइप कर सकते हैं ।
क्या आप अभी यह अनुमान लगा रहे हैं कि यह अवधारणा अब कितनी शक्तिशाली है?
एक पाइप्ड टेक्स्ट स्ट्रीम प्रोग्राम के दृष्टिकोण से एक फ़ाइल से अप्रभेद्य है, सिवाय इसके कि यह अप्रत्यक्ष है। एक पाइप से एक प्रोग्राम उसी तरह से पढ़ता है जिस तरह से यह एक फाइल से पढ़ता है: एक फाइल डिस्क्रिप्टर के माध्यम से । एफडी यूनिक्स के लिए बिल्कुल मूल हैं; यह तथ्य कि दोनों पर I / O के लिए फ़ाइलें और पाइप एक ही अमूर्त का उपयोग करते हैं, आपको कुछ बताना चाहिए ।⁹
विंडोज दुनिया, साधारण पाठ संचार की इस परंपरा की कमी है, बनाता है दिग्गज के साथ क्या OOP के माध्यम से इंटरफेस COM या नेट । यदि आपको ऐसे प्रोग्राम को स्वचालित करने की आवश्यकता है, तो आपको एक COM या .NET प्रोग्राम भी लिखना होगा। यह एक यूनिक्स बॉक्स पर एक पाइप स्थापित करने की तुलना में काफी कठिन है।
इन जटिल प्रोग्रामिंग एपीआई की कमी वाले विंडोज प्रोग्राम केवल क्लिपबोर्ड या फ़ाइल / सेव के बाद फ़ाइल / ओपन जैसे खराब इंटरफेस के माध्यम से संवाद कर सकते हैं।
लंबे उत्तर, भाग 3: रजिस्ट्री बनाम कॉन्फ़िगरेशन फ़ाइलें
विंडोज रजिस्ट्री और यूनिक्स वे ऑफ सिस्टम कॉन्फ़िगरेशन के बीच व्यावहारिक अंतर "सब कुछ एक फ़ाइल है" दर्शन के लाभों को दिखाता है।
यूनिक्स प्रकार की प्रणालियों पर, मैं केवल फाइलों की जांच करके कमांड लाइन से सिस्टम कॉन्फ़िगरेशन की जानकारी देख सकता हूं। मैं उन्हीं फाइलों को संशोधित करके सिस्टम व्यवहार को बदल सकता हूं। अधिकांश भाग के लिए, ये कॉन्फ़िगरेशन फ़ाइलें सिर्फ सादा पाठ फ़ाइलें हैं, जिसका अर्थ है कि मैं यूनिक्स पर किसी भी उपकरण का उपयोग उन्हें हेरफेर करने के लिए कर सकता हूं जो सादे पाठ फ़ाइलों के साथ काम कर सकता है।
रजिस्ट्री को स्क्रिप्ट करना विंडोज पर लगभग इतना आसान नहीं है।
सबसे आसान तरीका है कि एक मशीन पर रजिस्ट्री संपादक जीयूआई के माध्यम से अपने बदलाव करें, फिर उन बदलावों को फ़ाइलों के regeditमाध्यम से अन्य मशीनों पर आँख बंद करके लागू *.regकरें । यह वास्तव में "स्क्रिप्टिंग" नहीं है, क्योंकि यह आपको सशर्त रूप से कुछ भी नहीं करने देता है: यह सब या कुछ भी नहीं है।
यदि आपके रजिस्ट्री परिवर्तनों को किसी भी तर्क की आवश्यकता है, तो सबसे आसान विकल्प PowerShell सीखना है , जो मूल रूप से .NET सिस्टम प्रोग्रामिंग सीखने के लिए है। यह ऐसा होगा जैसे कि यूनिक्स के पास केवल पर्ल है, और आपको इसके माध्यम से सभी तदर्थ प्रणाली प्रशासन करना होगा। अब, मैं एक पर्ल प्रशंसक हूं, लेकिन हर कोई नहीं है। यूनिक्स आपको किसी भी उपकरण का उपयोग करने देता है जो आपको पसंद है, जब तक यह सादे पाठ फ़ाइलों में हेरफेर कर सकता है।
फुटनोट:
योजना 9 इस डिजाइन misstep तय, नेटवर्क आई / ओ उजागर के माध्यम से आभासी फाइल सिस्टम ।/net
बैश में एक विशेषता होती/dev/tcp है, जो नेटवर्क I / O को नियमित फाइलसिस्टम फ़ंक्शन के माध्यम से अनुमति देती है। चूंकि यह एक बैश फीचर है, बल्कि कर्नेल फीचर है, यह बैश के बाहर या उन सिस्टम पर दिखाई नहीं देता है जो बैश का उपयोग बिल्कुल नहीं करते हैं । यह दिखाता है कि, काउंटरएक्सप्लिमेंट द्वारा, फाइल सिस्टम के माध्यम से सभी डेटा संसाधनों को दिखाई देना इतना अच्छा क्यों है।
"आधुनिक विंडोज," से मेरा मतलब है विंडोज एनटी और इसके सभी प्रत्यक्ष वंशज, जिसमें विंडोज 2000, विंडोज सर्वर के सभी संस्करण और एक्सपी आगे से विंडोज के सभी डेस्कटॉप-उन्मुख संस्करण शामिल हैं। मैं विंडोज के डॉस-आधारित संस्करणों को बाहर करने के लिए शब्द का उपयोग करता हूं, विंडोज 95 और इसके प्रत्यक्ष वंशज, विंडोज 98 और विंडोज एमई, साथ ही उनके 16-बिट पूर्ववर्तियों।
आप उन बाद वाले OSes में एकीकृत I / O सिस्टम की कमी से अंतर देख सकते हैं। आप ReadFile()विंडोज 95 पर एक टीसीपी / आईपी सॉकेट पास नहीं कर सकते हैं ; आप केवल Windows सॉकेट APIs के लिए सॉकेट पास कर सकते हैं। एंड्रयू शुलमैन का सेमिनल लेख देखें, विंडोज 95: इस विषय में गहराई से गोता लगाने के लिए क्या नहीं है ।
कोई गलती न करें, /dev/nullयूनिक्स प्रकार सिस्टम पर एक वास्तविक कर्नेल डिवाइस है, न कि केवल एक विशेष-केसेड फ़ाइल नाम, जैसा कि NULविंडोज में सतही समकक्ष है।
हालाँकि, Windows आपको NULफ़ाइल बनाने से रोकने की कोशिश करता है , लेकिन यह संभव है कि आप केवल चालबाजी के साथ इस सुरक्षा को दरकिनार करें , Windows के फ़ाइल नाम पार्सिंग लॉजिक को बेवकूफ बनाना। यदि आप उस फ़ाइल को cmd.exeएक्सप्लोरर या एक्सप्लोरर के साथ एक्सेस करने का प्रयास करते हैं , तो विंडोज इसे खोलने से इंकार कर देगा, लेकिन आप इसे साइगविन के माध्यम से लिख सकते हैं, क्योंकि यह उदाहरण प्रोग्राम के समान तरीकों का उपयोग करके फाइलें खोलता है, और आप इसे समान चाल के माध्यम से हटा सकते हैं ।
इसके विपरीत, यूनिक्स ख़ुशी से आपको तब तक देगा rm /dev/null, जब तक आपके पास लिखने के लिए पहुंच है /dev, और आपको इसकी जगह एक नई फ़ाइल को फिर से बनाने की अनुमति देता है, सभी बिना किसी चालबाजी के, क्योंकि वह देव नोड सिर्फ एक और फ़ाइल है। जबकि वह देव नोड गायब है, कर्नेल की अशक्त डिवाइस अभी भी मौजूद है; यह केवल दुर्गम है जब तक आप देव नोड को फिर से नहीं बनाते हैं mknod।
आप कहीं और अतिरिक्त नल डिवाइस देव नोड्स भी बना सकते हैं: इससे कोई फर्क नहीं पड़ता कि आप इसे कॉल करते हैं /home/grandma/Recycle Bin, जब तक यह नल डिवाइस के लिए एक देव नोड है, यह ठीक उसी तरह काम करेगा /dev/null।
विंडोज में वास्तव में दो उच्च-स्तरीय "प्रारूप डिस्क" एपीआई हैं: SHFormatDrive()और Win32_Volume.Format()।
वहाँ दो के लिए एक बहुत ... अच्छी तरह से कर रहे हैं ... Windows कारण की तरह। पहला व्यक्ति विंडोज एक्सप्लोरर को अपना सामान्य "फॉर्मेट डिस्क" डायलॉग बॉक्स प्रदर्शित करने के लिए कहता है, जिसका अर्थ है कि यह विंडोज के किसी भी आधुनिक संस्करण पर काम करता है, लेकिन केवल तब जब कोई उपयोगकर्ता अंतःक्रियात्मक रूप से लॉग इन होता है। दूसरा जिसे आप उपयोगकर्ता इनपुट के बिना पृष्ठभूमि में कॉल कर सकते हैं। लेकिन यह विंडोज सर्वर 2003 तक विंडोज में नहीं जोड़ा गया था। यह सही है, कोर ओएस व्यवहार 2003 तक एक जीयूआई के पीछे छिपा हुआ था, एक ऐसी दुनिया में जहां यूनिक्स mkfs 1 दिन से भेज दिया गया था ।
1974 से यूनिक्स वी 5 की मेरी कॉपी में/etc/mkfs 4136 बाइट स्टेटिकली लिंक्ड पीडीपी -11 एक्जीक्यूटेबल शामिल है। ( 1980 के दशक के उत्तरार्ध तक यूनिक्स को डायनेमिक लिंकेज नहीं मिला , इसलिए ऐसा नहीं है कि एक बड़ा पुस्तकालय कहीं और है जो सभी वास्तविक कार्य कर रहा है।) इसका स्रोत कोड - V5 सिस्टम छवि में शामिल है /usr/source/s2/mkfs.c- एक पूरी तरह से आत्म-निहित 457- है लाइन सी कार्यक्रम। वहाँ भी कोई #includeबयान नहीं कर रहे हैं !
इसका मतलब है कि आप केवल mkfsउच्च स्तर पर क्या करता है, इसकी जांच नहीं कर सकते हैं , आप उसी उपकरण सेट का उपयोग करके इसके साथ प्रयोग कर सकते हैं जैसे यूनिक्स चार दशक पहले केन थॉम्पसन के साथ बनाया गया था। विंडोज के साथ कोशिश करें। निकटतम आप आज आ सकते हैं, डॉस स्रोत कोड को डाउनलोड करने के लिए , पहली बार 2014 में जारी किया गया था , जिसे आप केवल विधानसभा स्रोतों के ढेर में पाते हैं। यह केवल अप्रचलित टूल के साथ ही निर्मित होगा, जो संभवतः आपके पास नहीं होगा, और अंत में आपको डॉस 2.0 की अपनी खुद की प्रतिलिपि प्राप्त होगी, 1974 के यूनिक्स वी 5 की तुलना में बहुत कम शक्तिशाली , इसके लगभग एक दशक बाद जारी होने के बावजूद।
(यूनिक्स वी 5 के बारे में क्यों बात करें? क्योंकि यह अभी भी उपलब्ध सबसे पहले यूनिक्स प्रणाली है। पहले के संस्करण स्पष्ट रूप से समय के लिए खो गए हैं । एक परियोजना थी जो एक वी 1 / वी 2 युग यूनिक्स के साथ मिलकर mkfsपाई गई थी , लेकिन यह अस्तित्व के बावजूद गायब प्रतीत होता है। ऊपर दिए गए V1 मैनुअल पेज से यह साबित होता है कि वह कहीं न कहीं, कहीं न कहीं मौजूद रहा होगा। या तो इस परियोजना को एक साथ रखने वालों mkfsको शामिल करने के लिए एक प्रतिलिपि नहीं मिल पाई , या मैं बिना फाइलों को खोजे चूसता हूं find(1), जो उस प्रणाली में भी मौजूद नहीं है। । :))
अब, आप सोच रहे होंगे, "क्या मैं सिर्फ कॉल नहीं कर सकता format.com? क्या यह विंडोज mkfsपर यूनिक्स पर कॉल करने के समान नहीं है ?" काश, नहीं, यह कारणों की एक गुच्छा के लिए एक ही नहीं है:
सबसे पहले, format.comस्क्रिप्ट करने के लिए डिज़ाइन नहीं किया गया था। यह आपको "जब तैयार हो तो एंटर दबाएं" के लिए प्रेरित करता है, जिसका अर्थ है कि आपको इसके इनपुट में एंटर कुंजी भेजने की आवश्यकता है, या यह बस लटका रहेगा।
फिर, यदि आप एक सफलता / विफलता स्थिति कोड से अधिक कुछ भी चाहते हैं, तो आपको पढ़ने के लिए इसके मानक आउटपुट को खोलना होगा, जो कि विंडोज पर कहीं अधिक जटिल है जितना कि यह होना चाहिए । (यूनिक्स पर, उस जुड़े लेख में सब कुछ एक साधारण popen(3)कॉल के साथ पूरा किया जा सकता है ।)
इस सभी जटिलता से गुजरने के बाद , मुख्य रूप से मानव उपभोग के उद्देश्य से, format.comकंप्यूटर प्रोग्राम के लिए पार्स करना कठिन है mkfs।
आप का पता लगाने के क्या हैं format.comकरता है, आपको लगता है कि यह करने के लिए जटिल कॉल का एक समूह मिल नहीं जाता DeviceIoControl(), ufat.dllऔर इस तरह के। यह केवल एक डिवाइस फ़ाइल नहीं खोल रहा है और उस डिवाइस पर एक नया फाइल सिस्टम लिख रहा है। इस डिजाइन की तरह आप से मिलता है एक कंपनी है कि 126000 लोगों को रोजगार , और करने की जरूरत है रखने के लिए उन्हें रोजगार।
जब लूप उपकरणों के बारे में बात की जाती है, तो मैं सामान्य रूप से केवल यूनिक्स के बजाय लिनक्स के बारे में बात करता हूं क्योंकि लूप डिवाइस यूनिक्स प्रकार प्रणालियों के बीच पोर्टेबल नहीं हैं। ओएस एक्स, बीएसडी, आदि में समान तंत्र हैं, लेकिन सिंटैक्स कुछ हद तक भिन्न होता है ।
उन दिनों में जब डिस्क ड्राइव वाशिंग मशीन के आकार के थे और विभाग के प्रमुख की लक्जरी कार की तुलना में अधिक लागत थी, बड़े कंप्यूटर लैब आधुनिक कंप्यूटिंग वातावरण की तुलना में अपने सामूहिक डिस्क स्थान का एक बड़ा हिस्सा साझा करेंगे। स्थानीय फ़ाइल सिस्टम में एक दूरस्थ डिस्क को पारदर्शी रूप से ग्राफ्ट करने की क्षमता ने ऐसे वितरित सिस्टम को उपयोग करने के लिए बहुत आसान बना दिया। यह वह जगह है जहाँ हम प्राप्त करते हैं /usr/share, उदाहरण के लिए।
कंट्रास्ट विंडोज, जहां एक दूरस्थ डिस्क आमतौर पर या तो ड्राइव अक्षर पर मैप की जाती है या स्थानीय फाइल सिस्टम में एकीकृत पारदर्शिता के बजाय एक यूएनसी पथ के माध्यम से एक्सेस की जानी चाहिए। ड्राइव अक्षर आपको प्रतीकात्मक अभिव्यक्ति के लिए कुछ विकल्प प्रदान करते हैं; करता P:BigServer पर, या सॉफ्टवेयर दर्पण सर्वर पर "संकुल" निर्देशिका "सार्वजनिक" अंतरिक्ष का उल्लेख? UNC रास्तों का मतलब है कि आपको याद रखना होगा कि आपकी रिमोट फाइल किस सर्वर पर है, जो सैकड़ों या हजारों फ़ाइल सर्वरों वाले बड़े संगठन में मुश्किल हो जाती है।
Windows को 2007 में रिलीज़ हुए Windows Vista तक सहानुभूति नहीं मिली, जिसने NTFS प्रतीकात्मक लिंक पेश किए । विंडोज के प्रतीकात्मक लिंक यूनिक्स के प्रतीकात्मक लिंक की तुलना में थोड़ा अधिक शक्तिशाली हैं - 1977 से यूनिक्स की एक विशेषता - इसमें वे एक दूरस्थ फ़ाइल साझा करने के लिए भी कह सकते हैं, न कि केवल एक स्थानीय पथ पर। यूनिक्स ने 1984 में एनएफएस के माध्यम से अलग तरीके से किया , जो यूनिक्स के preexisting माउंट बिंदु सुविधा के शीर्ष पर है , जो कि शुरुआत से ही रहा है।
तो, आप इसे कैसे देखते हैं, इस पर निर्भर करते हुए, विंडोज ने लगभग 2 या 3 दशकों तक यूनिक्स को फंसाया।
फिर भी, प्रतीकात्मक लिंक कुछ कारणों से विंडोज उपयोगकर्ता के अनुभव का सामान्य हिस्सा नहीं हैं।
सबसे पहले, आप उन्हें केवल बैकवर्ड कमांड लाइन प्रोग्राम के साथ बना सकते हैं MKLINK। आप उन्हें Windows Explorer से नहीं बना सकते, जबकि विंडोज एक्सप्लोरर के लिए यूनिक्स समकक्ष आम तौर पर करते हैं आप सिमलिंक बना सकते हैं।
दूसरा, डिफ़ॉल्ट विंडोज कॉन्फ़िगरेशन सामान्य उपयोगकर्ताओं को प्रतीकात्मक लिंक बनाने से रोकता है , यह आवश्यक है कि आप कमांड शेल को प्रशासक के रूप में चलाएं या उपयोगकर्ता को उन्हें एक अस्पष्ट पथ के माध्यम से बनाने की अनुमति दें जो आपके औसत उपयोगकर्ता ने कभी नहीं देखा है, बहुत कम जानता है कैसे इस्तेमाल करे। (और विंडोज में अधिकांश व्यवस्थापक विशेषाधिकार समस्याओं के विपरीत, यूएसी इस मामले में कोई मदद नहीं करता है।)
लिनक्स बॉक्स हमेशा बूट अनुक्रम में एक आभासी डिस्क छवि का उपयोग नहीं करते हैं। कर रहे हैं यह करने के लिए अलग अलग तरीकों का एक समूह ।
man ed
नेटवर्क सॉकेट डिस्क्रिप्टर नीचे से एफडी हैं, वैसे भी।