किस सिस्टम पर // foo / bar / foo / bar से अलग है?

114

POSIX विनिर्देश में, विशेष रूप से दो के साथ शुरू होने वाले पथ के उपचार के लिए कार्यान्वयन की अनुमति देने के लिए प्रावधान ( 1 , 2 , 3 ...) है /।

एक POSIX एप्लिकेशन (सभी POSIX आज्ञाकारी प्रणालियों के लिए पोर्टेबल होने के लिए POSIX विनिर्देश के लिए लिखा गया एक अनुप्रयोग) यह मान नहीं सकता है कि //foo/barयह /foo/bar(हालांकि वे मान सकते हैं कि ///foo/barजैसा है /foo/bar)।

अब वे पोसिक्स सिस्टम (ऐतिहासिक और अभी भी बनाए हुए) क्या हैं जो //fooविशेष रूप से व्यवहार करते हैं ? मुझे विश्वास था (मैं अब गलत साबित हो गया हूं ) कि पोसिक्स प्रावधान को उनके यूनिक्स संस्करण (एक्सईएनएक्स) और संभवत: विंडोज पॉसिक्स परत (क्या कोई पुष्टि कर सकता है?) के लिए माइक्रोसॉफ्ट द्वारा धक्का दिया गया था।

इसका उपयोग Cygwin द्वारा किया जाता है जो Microsoft Windows के लिए एक POSIX जैसी परत है। क्या कोई गैर-माइक्रोसॉफ्ट विंडोज सिस्टम हैं? ओपन VMS?

सिस्टम पर जहां //foo/barविशेष है, इसका उपयोग किस लिए किया जाता है? //host/pathनेटवर्क फ़ाइल सिस्टम एक्सेस के लिए? वर्चुअल फाइल सिस्टम?

यूनिक्स-लाइक पर चलने वाले कुछ एप्लिकेशन क्या-क्या सिस्टम के एपीआई नहीं हैं- //foo/barपथों का विशेष रूप से व्यवहार करते हैं (संदर्भों में जहां वे अन्यथा /foo/barफाइल सिस्टम पर पथ के रूप में व्यवहार करते हैं )?

संपादित करें , मैंने तब से ऑस्टिन-ग्रुप मेलिंग सूची पर सवाल पूछा है//foo/bar जो कल्पना में हैंडलिंग की उत्पत्ति के बारे में है, और चर्चा एक दिलचस्प रीड (पुरातत्व की दृष्टि से कम से कम) है।

filenames  history  portability  slash 
— स्टीफन चेज़लस
स्रोत
1
— स्टीफन चेज़लस
1
@OlivierDulac, No. ls -ld ///भी प्रदर्शित करेगा ///, lsबस उस फ़ाइल को प्रदर्शित करता है जिसे यह बताया जा रहा है कि वह दी गई थी। मैं ऐसे सिस्टम या एप्लिकेशन की तलाश कर रहा हूं, जो साइगविन की तरह विशेष रूप से (फाइल सिस्टम पर पथ के रूप में) foo / var का इलाज नहीं करता है।
— स्टीफन चेजलस
1
मानक ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ) का कहना है, जैसा कि आपने उल्लेख किया है, "एक पथनाम जो दो क्रमिक स्लैश के साथ शुरू होता है, उसे कार्यान्वयन-परिभाषित तरीके से व्याख्या किया जा सकता है" (2 से अधिक 1 / को हल करता है) । नेट पर एक उदाहरण मिला: austingroupbugs.net/view.php?id=83 ( IBM's z/OS resolves //pathname requests to MVS datasets (as opposed to the hierarchical filesystem (HFS)) (......) Additionally, z/OS would not accept or recognize additional "directory" or "file" components appended to such paths.... बिल्कुल यूनिक्स नहीं, हालांकि ^ ^)।
— ओलिवियर दुलक
4
@DevSolar: वास्तव में इंटररस्टिंग (और आश्चर्यजनक), लेकिन हमें केवल POSIX से चिपके रहना चाहिए, क्योंकि POSIX में से कुछ भी संभव है ^ ^
— ओलिवियर डुलैक
2
@edwardtorvalds क्योंकि पहला बिट URL है: और file://समान http://। क्रोम पर यहाँ काम करने के लिए एक विंडोज़ यूएनसी पथ है जिसे मैंने अभी खोला है file:////$MACHINE/$SHARENAME/index.html(हालांकि किसी कारण से यह भी समझता है file://$MACHINE/...)
— सराहा

जवाबों:

90

यह अब तक दिए गए उत्तरों का संकलन और सूचकांक है। यह पोस्ट सामुदायिक विकी है , इसे 100+ प्रतिष्ठा वाले किसी भी व्यक्ति द्वारा संपादित किया जा सकता है और किसी को इससे प्रतिष्ठा नहीं मिलती है। बेझिझक अपना जवाब पोस्ट करें और इसमें एक लिंक यहाँ जोड़ें (या मुझे इसके लिए प्रतीक्षा करें)। आदर्श रूप में, यह उत्तर केवल एक सारांश होना चाहिए (छोटी प्रविष्टियों के साथ जबकि अन्य उत्तर में विवरण होगा)।

वर्तमान में सक्रिय रूप से बनाए रखा सिस्टम:

कमी प्रणाली

अनुप्रयोग जो //foo/barपथ के लिए विशेष रूप से व्यवहार करते हैं

— स्टीफन चेज़लस
स्रोत
3
//नाम का उपयोग करना कुछ लिनक्स कर्नेल डेवलपर्स द्वारा Reiser4 की मेटाडेटा सुविधाओं के लिए प्रस्तावित किया गया था, लेकिन मुझे नहीं लगता कि यह प्रस्ताव कभी भी नेमेस के भीतर कर्षण प्राप्त हुआ था, और न ही इसे कभी लागू किया गया था।
— जॉर्ग डब्ल्यू मित्तग
विंडोज़ खुद पोसिक्स एपीआई को लागू करता है ... यह एक प्रमुख दोहरे स्लैश को कैसे संभालता है?
— केविन
1
हम इसे वेब पर जोड़ सकते हैं, डबल स्लैश से शुरू होने वाले संसाधन एकल स्लैश की तुलना में एक अलग रूट को परिभाषित करते हैं।
— एलेक्स गैटमेयर
@ केविन, हां मैं भी इसे मानता हूं (प्रश्न देखें), हालांकि मुझे लगता है कि यह एक वैकल्पिक घटक था और केवल विंडोज के कुछ वेरिएंट पर और अब बंद हो गया है। यदि आपके पास अधिक विवरण हैं, तो कृपया एक उत्तर जोड़ें।
— स्टीफन चेज़लस
— स्टीफन चेज़लस
16

यूनिक्स पर चलने वाले कुछ एप्लिकेशन पसंद करते हैं — क्या सिस्टम का एपीआई-इलाज // फू / बार पाथ खास नहीं है?

मैं पेरफोर्स से अवगत हूं जो //depot/A/B/C/Dडिपो को संदर्भित करने के लिए पथ का उपयोग करता है । //Client/C/Dजब ग्राहक इंगित कर रहा होता है, तो Perforce पथों का भी समर्थन करता है //depot/A/B/। यहां, स्थानीय फ़ाइल सिस्टम में ये पथ नहीं हो सकते हैं।

p4 filelog //depot/A/B/C/Dउस फ़ाइल का इतिहास दिखाएगा, भले ही कोई फ़ाइल न हो /depot/A/B/C/D।

p4 filelog C/D उपयुक्त निर्देशिका से निष्पादित होने पर, उस फ़ाइल का इतिहास भी दिखाएगा।

संदर्भ: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

— प्रेम
स्रोत
13

कई दशक पहले, Tektronix Utek (BSD 4.2 आधारित यूनिक्स, राष्ट्रीय अर्धचालक पर पहले 32,016 सीपीयू तो मोटोरोला 68020 रों) कुछ डीएफएस (वितरित फ़ाइल प्रणाली) है जिसके तहत कहा जाता है प्रदान किया गया था //foo/barकरने के लिए बात कर रहे थे /barपर फ़ाइल fooDFS सर्वर। बाद में सन के एनएफएस द्वारा इसका पालन किया गया।

दुर्भाग्य से, मैंने अभी तक इसका संदर्भ नहीं दिया है, लेकिन मैं अंततः अपने सेलर में कुछ यूटेक प्रलेखन पा सकता हूं और इस उत्तर को अपडेट कर सकता हूं।

— jlliagre
स्रोत
1
— usenet
@ स्टीफनचेज़ेलस मेरा मानना ​​है कि यूज़नेट चर्चा का यह लिंक बेहतर है। आपके द्वारा चुना गया डोमेन / OS है, लेकिन Utek नहीं है। या अगला संदेश (आप से)
— स्टीफन चेज़लस
Tektronix / BSD आरएफएस कार्यान्वयन जाहिरा तौर परfind माउंट बिंदु पर आघात से बचने के लिए नियमित फाइलों पर दूरस्थ फ़ाइल सिस्टम को माउंट करते हैं। लेखक ने स्पष्ट रूप से नियम //foo/bar(या न्यूकैसल कनेक्शन के /../foo/bar) वहाँ
— स्टीफन चेज़लस
— usenet
7

इस उत्तर से प्रमुख का अनुसरण करें । और Bitsavers (धन्यवाद @grawity ) से मैनुअल से पेज 2-15 पढ़ना ।

साझा डेटा
डोमेन / OS का दूसरा डिज़ाइन सिद्धांत वितरित फ़ाइल सिस्टम, डिफ़ॉल्ट रूप से साझा करना, एक वैश्विक समान नाम स्थान को दर्शाता है। वितरित फ़ाइल सिस्टम का नाम स्थान उपयोगकर्ताओं को एक विशाल टाइमशेयरिंग फ़ाइल सिस्टम की तरह दिखाई देता है। यह एक पारंपरिक UNIX पदानुक्रमित नाम स्थान है, सिवाय इसके कि पूर्ण पथनाम नेटवर्क रूट (जिसे // कहा जाता है) के नाम से शुरू हो सकता है। स्थानीय नोड (/ निर्देशिका) की जड़ के सापेक्ष पथनामों को व्यक्त करना भी संभव है।

"पहले मुद्रण: जुलाई, 1985" के साथ एक पुराना मैनुअल भी है । पृष्ठ 1-4 पर:

चित्र 1-2 में डबल स्लैश (//) नामकरण पेड़ के शीर्ष स्तर का प्रतिनिधित्व करते हैं, नेटवर्क रूट डायरेक्टरी।

तो, हमारे पास पुष्टि है कि //नेटवर्क रूट के लिए प्रयुक्त अपोलो से डोमेन / ओएस ।

— समुदाय
स्रोत
मुझे लगता है कि विशालकाय आदमी एक प्रमुख कट्टर लिनक्स देव है ।
— mikeserv
5

एक अन्य अनुप्रयोग: ब्लेंडर एक अग्रणी //को प्रोजेक्ट डायरेक्टरी (जिस डायरेक्टरी में .blendफाइल सेव की जाती है) के संदर्भ के रूप में मानता है । यहां प्रासंगिक मैनुअल पृष्ठ है ।

यह गैर-यूनिक्स जैसे ऑपरेटिंग सिस्टम (यानी, विंडोज) के लिए भी सही है।

— wchargin
स्रोत
5

ReactOS परियोजना - NT कर्नेल और संबंधित APIs के एक स्वतंत्र और खुला स्रोत कार्यान्वयन है जो - जाहिरा तौर पर भी अपने आप ही लागू करने के लिए कार्य शुरू किया है Interix तरह POSIX सबसिस्टम (हालांकि एमएस के मूल OS / 2 सबसिस्टम भी है संदर्भ में उल्लेख किया है , कोई जिक्र नहीं एक ReactOS एनालॉग से बना है) ।

हालांकि अब तक के प्रयास छोटे हैं , लेकिन fork()यह वास्तव में एक वास्तविकता है। यहाँ सबसिस्टम के परियोजना पृष्ठ का एक अंश है, जैसा कि खुले मुद्दों के तहत सूचीबद्ध है :

पथ

POSIX अनुप्रयोगों में Win32 रास्तों का उपयोग करने का सबसे अच्छा तरीका क्या है? विचार:

  • अनुवाद //<device>/<path> में \\.\<device>\<path> (ड्राइव अक्षर के लिए एक विशेष मामले के साथ - //<letter>/<path>=> <letter>:\<path>- और विशेष भागने //./<raw text>=> \\.\<raw text>। यूएनसी पथ के साथ निर्दिष्ट किया जा सकता है //unc/<path>) । //कार्यान्वयन-विशिष्ट व्यवहार के लिए मानक मानक द्वारा आरक्षित हैं, और //<letter>/Win32 पथ से बचने के लिए सिंटैक्स मौजूदा PIXIX वातावरण में व्यापक रूप से उपयोग किया जाता है

  • "नंगे" Win32 पथों को इस तरह से पहचानने के लिए आंकड़े

  • Win32 पथ और //पथ के लिए केस-असंवेदनशील लुकअप (क्या// पथ के लिए इस तरह के कार्यान्वयन-विशिष्ट व्यवहार की अनुमति देता है?) ।

मुझे यकीन नहीं है कि यह कैसे योग्य है क्योंकि मुझे यकीन नहीं है कि इसे कितना लागू किया गया है, लेकिन मुझे लगा कि यह समस्या का एक उपयोगी दिलचस्प वर्णन था।

— mikeserv
स्रोत
XENIX में POSIX सबसिस्टम नहीं था , विंडोज में AFAIK था। XENIX एक यूनिक्स था (शुरुआत में यूनिक्स V7 पर आधारित था जिसे Microsoft ने AT & T का लाइसेंस खरीदा था)।
— स्टीफन चेजलस
1
यहाँ अच्छा पढ़ें साथ ही साथ इंटरिक्स / विंडोज पोसिक्स सबसिस्टम
— स्टीफन चेज़लस
@ स्टीफनचेज़लस - काफी। मैं लगभग इसके साथ अपने लिंक को बदलना चाहता हूं, लेकिन यह थोड़ा राय-आधारित है, और वास्तव में एक संदर्भ के रूप में काम नहीं करता है ... लेकिन टिप्पणी को हटाएं नहीं, कृपया?
— मोकेसर
किसी भी मामले में, यह //foo/barहैंडलिंग का उल्लेख नहीं करता है । मुझे मजबूत सबूत नहीं मिले हैं विंडोज पॉसिक्स सबसिस्टम या इंटरिक्स ने वास्तव में उन्हें अब तक संभाला है।
— स्टीफन चेज़लस
@ स्टीफनचेलजैस - मुझे पता है कि अगर यह बहुत ही असंगत था, या यदि वैकल्पिक रूप से भाग को छोड़ना सिर्फ एक निरीक्षण था, लेकिन एमकेएस lsaclकमांड को समझना होगा, \\machinename\driveletter:\pathजबकि इसकी registryकमान को उस रूप में समझने का अनुमान था या वैकल्पिक रूप से// दोनों तरह से। चूंकि एमकेएस किट इंटरिक्स का पूर्ववर्ती था और एमएस के संस्करणों के लिए एमएस को भेजा गया था। मुझे लगता है कि इंटरिक्स ने इस तरह की बुनियादी चीज के लिए संगत वाक्यविन्यास स्वीकार किया होगा।
— मोकेसर
4

1980 के दशक में, SEL / Gould में एक यूनिक्स ऑपरेटिंग सिस्टम था, जिसे UTX-32 कहा जाता था , जो सोलारिस में बराबर था ; यानी, मेजबान पर दूर से पहुंच पथ । मुझे इस पर कोई दस्तावेज नहीं मिल रहा है, इसलिए मुझे नहीं पता कि यह RFS था या समानांतर विकास (या क्या एटी एंड टी//host/path/net/host/pathpathhostचुरा लिया इसे Gould से हासिल किया)।

— स्कॉट
स्रोत
धन्यवाद। क्या आप किसी भी संयोग से उस पर ( //host/pathUTX-32 में) कोई संदर्भ देंगे ?
— स्टीफन चेजलस
यह संभव है कि मेरे अटारी में एक बॉक्स में एक हार्ड-कॉपी दस्तावेज़ है, लेकिन संभावना नहीं है - (1) मुझे कभी भी बहुत सारे दस्तावेज याद नहीं हैं (मुझे पांच मिनट की मौखिक ब्रीफिंग याद है); (२) यदि मेरे पास होता तो भी मैं इसे घर नहीं ले जाता; (३) भले ही मैंने इसे घर ले लिया हो, मैंने शायद पिछले ३० सालों में इसे कुछ समय के लिए फेंक दिया; और (4) अगर मेरे पास अभी भी है, तो मैं शायद इसे नहीं पा सकूंगा। ओह, यह भी (0) मैंने अपना उत्तर पोस्ट करने से पहले पांच मिनट इसे Googling (कोई फायदा नहीं हुआ) के लिए बिताया।
— स्कॉट
4

मेरे पास एक अस्पष्ट याद है कि //host/pathसंकेतन का उपयोग AT & T SysV.3 पर इसके RFS रिमोट फाइल शेयरिंग कार्यान्वयन के हिस्से के रूप में किया गया था । यह अंततः उस समय के आसपास छोड़ दिया गया था जब SysV.4 को सन माइक्रोसिस्टम्स के सरल लेकिन अधिक लोकप्रिय NFS के पक्ष में जारी किया गया था ।

हालाँकि, मुझे सिंटैक्स के लिए कोई ठोस संदर्भ नहीं मिल सकता है, और मैंने अभी जो दस्तावेज़ की समीक्षा की है, उससे यह संकेत मिलता है कि उपयोगकर्ता को दूरस्थ होस्टनाम निर्दिष्ट करने के विचार से स्थान स्वतंत्रता के डिज़ाइन सिद्धांत का विरोध किया गया होगा।

संदर्भ 1. आरएफएस वास्तुकला अवलोकन

— roaima
स्रोत
3
Founf इस आरएफएस के बारे में। मुझे इसका संदर्भ नहीं मिल रहा है //host/path। ऐसा लगता है कि नेटवर्क फ़ाइल सिस्टम को स्पष्ट रूप से माउंट किया जाना है।
— स्टीफन चेजलस
याद दिलाने के लिए शुक्रिया। यह "मेरे द्वारा समीक्षा किए गए दस्तावेज़" के टुकड़ों में से एक है, इसलिए यदि आप बुरा नहीं मानते हैं तो मैं इसमें एक लिंक जोड़ूंगा। मैं अभी भी इस पर हैरान हूँ; अगले दिन यह मेरे पास आ सकता है।
— रोइमा
4

POSIX में कहा गया दलील A.4.12 पथ नाम संकल्प के लिए पैराग्राफ 9 और 10:

कुछ नेटवर्क सिस्टम में निर्माण /../hostname/ का उपयोग किसी अन्य होस्ट की रूट निर्देशिका को संदर्भित करने के लिए किया जाता है, और POSIX.1 इस व्यवहार को अनुमति देता है।

अन्य नेटवर्क सिस्टम एक ही उद्देश्य के लिए निर्माण // होस्टनाम का उपयोग करते हैं; यही है, एक डबल प्रारंभिक स्लैश का उपयोग किया जाता है।

यह पुष्टि करने के लिए लगता है कि //इसका मतलब है "नेटवर्क रूट", या कम से कम यह विचार तब था जब नियम को पोसिक्स में शामिल किया गया था।

//एक /आरंभ किए गए पथनाम के लिए एक मार्ग के बीच में किसी भी अर्थ को हटाने के लिए नियम का पालन करें :

... चूंकि दो या अधिक <स्लेश> वर्णों के गैर-प्रमुख दृश्यों को
एकल <स्लैश>, के रूप में माना जाता है ...

बेशक, एक //शुरू किया गया Pathname पाथनाम के //अंदर के उपयोग का विस्तार या परिवर्तन कर सकता है (शुरुआत में नहीं)। POSIX.1 यह अनुमति देता है। यह अंतिम पुष्टि करता है कि केवल //पथनाम की शुरुआत में अनुमति दी गई है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.