2009-07-23 18 views
5

मुझे पता है कि realpath() फ़ंक्शन के साथ फ़ाइल का पूर्ण पथ प्राप्त करना संभव है। हालांकि, बीयूजीएस अनुभाग के अनुसार मैनपेज, इसके कार्यान्वयन में कुछ समस्या है। विवरण निम्नलिखित हैं:लिनक्स के तहत रीयलपाथ() के साथ प्रोग्रामेटिक रूप से फ़ाइल का पूर्ण पथ कैसे प्राप्त करें?


बग

बचें इस समारोह का उपयोग कर। यह तब से डिज़ाइन द्वारा टूटा हुआ है जब तक कि गैर-मानक resolved_path == नल सुविधा का उपयोग न करें) आउटपुट बफर, resolved_path के लिए उपयुक्त आकार निर्धारित करना असंभव है। POSIX के अनुसार आकार PATH_MAX पर्याप्तता का बफर है, लेकिन PATH_MAX को परिभाषित निरंतर नहीं होना चाहिए, और पथक (3) का उपयोग करके प्राप्त किया जाना चाहिए। और pathconf (3) पूछना वास्तव में मदद नहीं करता है, क्योंकि एक तरफ POSIX चेतावनी देता है कि pathconf (3) का परिणाम स्मृति mallocing के लिए विशाल और अनुपयुक्त हो सकता है। और दूसरी तरफ pathconf (3) -1 को वापस संकेत दे सकता है कि PATH_MAX बाध्य नहीं है।

libc4 और libc5 कार्यान्वयन में एक बफर ओवरफ़्लो (libc-5.4.13 में तय) शामिल है। इस प्रकार, सेट-यूज़र-आईडी प्रोग्राम जैसे माउंट (8) को एक निजी संस्करण की आवश्यकता है।


तो सवाल यह है कि फ़ाइल का पूर्ण पथ प्राप्त करने का सबसे अच्छा अभ्यास क्या है?

+0

"[ओएस एक्स कमांड लाइन एप के पूर्ण पथ को प्रोग्रामेटिक रूप से पुनर्प्राप्त करने] का डुप्लिकेट (http://stackoverflow.com/questions/799679/programatically-retrieving-the-absolute-path-of-an-os- एक्स-आदेश-पंक्ति-ऐप) "? – bortzmeyer

+0

नहीं। वे एक ही बात नहीं हैं। मैं जानना चाहता हूं कि निष्पादन योग्य के बजाय सामान्य फ़ाइल का पूर्ण पथ कैसे प्राप्त करें। – jcadam

उत्तर

2

खोल से, मैं readlink -f $FILE का उपयोग कर एक पूर्ण पथ प्राप्त कर सकता हूं। ग्लिब में readlink() फ़ंक्शन है, शायद यह आपकी मदद करेगा।

# man 2 readlink 
+0

मैंने coreutils पैकेज में readlink कमांड के स्रोत कोड को पढ़ा है। एक साधारण समाधान है-बस PATH_MAX को 1024 तक परिभाषित करें !!!! -__- !!! – jcadam

3

उपयोग getcwd() और readlink() जो realpath reimplement करने के लिए एक बफर आकार देने के लिए अनुमति देता है()। ध्यान दें कि आपको प्रतीकात्मक लिंक हल करना होगा, "।" और ".." बाएं से दाएं इसे सही तरीके से करने के लिए।

5

मुझे पता है कि यह प्रश्न पुराना है, लेकिन मुझे कोई समस्या नहीं है जो मूल मुद्दे को संबोधित करता है: कम से कम दो कारणों से संदर्भित मैन पेज ओपी गलत और पुराना है।

एक यह है कि POSIX 2008 NULL तर्क विकल्प के लिए जोड़ा/अनिवार्य समर्थन है, जिससे realpath आपके लिए स्ट्रिंग आवंटित करता है। इस सुविधा का उपयोग करने वाले कार्यक्रम जीएनयू/लिनक्स के सभी प्रासंगिक संस्करणों के लिए पोर्टेबल होंगे, संभवतः अधिकांश अन्य आधुनिक सिस्टम, और पीओएसआईक्स 2008 के अनुरूप कुछ भी।

दूसरा कारण यह है कि मैन पेज गलत है PATH_MAX के खिलाफ सलाह है। यह "मनमानी सीमाओं" के खिलाफ पूरी तरह से जीएनयू धार्मिक विचारधारा है। वास्तविक दुनिया में, पथनाम की लंबाई सीमा नहीं होने से दुर्व्यवहार/डीओएस के लिए सभी प्रकार के रास्ते जोड़े जाएंगे, जो असफलता मामलों को उन कार्यों में जोड़ देगा जो अन्यथा विफल नहीं हो सकते हैं, और realpath की तुलना में अधिक इंटरफेस तोड़ देंगे।

यदि आप अधिकतम पोर्टेबिलिटी की परवाह करते हैं, तो संभवतः दोनों विधियों के मिश्रण का उपयोग करना सबसे अच्छा है। जानकारी के लिए POSIX दस्तावेज़ देखें:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html

मैं अगर PATH_MAX परिभाषित किया गया है एक निश्चित-आकार, फोन करने वाले के द्वारा उपलब्ध कराया बफर का प्रयोग करेंगे, और अन्यथा NULL गुजरती हैं। ऐसा लगता है कि सभी मामलों को कवर किया गया है, लेकिन आप यह देखने के लिए POSIX के पुराने संस्करणों को भी देखना चाहेंगे कि PATH_MAX परिभाषित नहीं होने पर उनके पास क्या करना है इसके लिए कोई दिशानिर्देश हैं या नहीं।

संबंधित मुद्दे