POSIX द्वारा परिभाषित फ़ाइल के रूप में फ़ाइल के लिए क्या शर्तें पूरी होनी चाहिए?

Question

POSIX एक पाठ फ़ाइल को परिभाषित करता है:

एक फ़ाइल जिसमें वर्ण शून्य या अधिक लाइनों में व्यवस्थित होते हैं। लाइनों में NUL वर्ण नहीं हैं और कोई भी <newline> वर्ण सहित लंबाई में {LINE_MAX} बाइट्स से अधिक नहीं हो सकता है। यद्यपि POSIX.1-2017 पाठ फ़ाइलों और बाइनरी फ़ाइलों (आईएसओ सी मानक देखें) के बीच अंतर नहीं करता है, कई उपयोगिताओं केवल पाठ फ़ाइलों पर काम करते समय अनुमानित या सार्थक आउटपुट उत्पन्न करती हैं। मानक उपयोगिताओं जिनके पास इस तरह के प्रतिबंध हैं, हमेशा अपने STDIN या INPUT FILES अनुभागों में "पाठ फ़ाइलों" को निर्दिष्ट करते हैं।

स्रोत: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403

हालांकि, ऐसी कई चीजें हैं जो मुझे अस्पष्ट लगती हैं:

1. पाठ फ़ाइल एक नियमित फ़ाइल होनी चाहिए? उपरोक्त अंश में यह स्पष्ट रूप से नहीं कहा गया है कि फ़ाइल एक नियमित फ़ाइल होनी चाहिए

2. क्या एक फ़ाइल को एक पाठ फ़ाइल माना जा सकता है यदि केवल एक वर्ण और एक वर्ण होता है (यानी, एक एकल वर्ण जिसे एक नई पंक्ति के साथ समाप्त नहीं किया जाता है)? मुझे पता है कि यह सवाल ध्वनिविहीन लग सकता है, लेकिन वे "एक या अधिक वर्ण" के बजाय "वर्ण" शब्द का उपयोग करते हैं। अन्य लोग असहमत हो सकते हैं, लेकिन अगर उनका मतलब "एक या अधिक वर्णों" से है, तो मुझे लगता है कि उन्हें स्पष्ट रूप से कहना चाहिए

3. उपरोक्त अंश में, यह "लाइनों" का संदर्भ देता है। मुझे उनके नाम में लाइन के साथ चार परिभाषाएँ मिलीं: "खाली लाइन", "डिस्प्ले लाइन", "अधूरी लाइन" और "लाइन"। क्या मुझे यह अनुमान लगाना चाहिए कि "खाली", "प्रदर्शन" और "अपूर्ण" के अपने चूक के कारण उनका मतलब "रेखा" है - या इन सभी परिभाषाओं में से चार समावेशी हैं जो ऊपर दिए गए अंश में एक पंक्ति मानी जा रही हैं?

पाठ के इस ब्लॉक के बाद आने वाले सभी प्रश्न इस बात पर निर्भर करते हैं कि "वर्ण" का अर्थ है "एक या अधिक वर्ण"

4. क्या मैं सुरक्षित रूप से अनुमान लगा सकता हूं कि यदि कोई फ़ाइल खाली है, तो यह एक पाठ फ़ाइल नहीं है क्योंकि इसमें एक या अधिक वर्ण नहीं हैं?

पाठ के इस ब्लॉक के बाद आने वाले सभी प्रश्न इस बात पर निर्भर करते हैं कि उपरोक्त अंश में, एक रेखा को "रेखा" के रूप में परिभाषित किया गया है, और यह कि उनके नाम में "रेखा" वाली अन्य तीन परिभाषाओं को बाहर रखा जाना चाहिए:

5. क्या "शून्य" "शून्य या अधिक लाइनों" में होने का मतलब है कि एक फ़ाइल को अभी भी एक पाठ फ़ाइल माना जा सकता है यदि इसमें एक या एक से अधिक वर्ण शामिल हैं जिन्हें नईलाइन के साथ समाप्त नहीं किया गया है?

6. क्या "शून्य या अधिक रेखाएं" का अर्थ है कि एक बार एक "लाइन" (0 या अधिक वर्णों और एक समाप्ति वाली नई रेखा) खेलने में आती है, कि यह अंतिम पंक्ति के लिए "अपूर्ण रेखा" (एक या अधिक गैर-) होना अवैध हो जाता है एक फ़ाइल के अंत में newline वर्ण)?

7. क्या "कोई भी [कोई भी रेखा] {LINE_MAX} बाइट्स को लंबाई में शामिल नहीं कर सकती है, जिसमें न्यूलाइन वर्ण भी शामिल है" का अर्थ है कि पाठ फ़ाइल में किसी भी "लाइन" में अनुमत वर्णों की संख्या तक सीमा (एक तरफ के रूप में, का मान) Ubuntu 18.04 पर LINE_MAX और फ्रीबीएसडी 11.1 "2048" है)?

Comments

अच्छा सवाल, हेरोल्ड! शब्दावली की एक महान चर्चा के लिए बनाता है। काश मैं इस सवाल को अतिरिक्त समय तक उठा पाता

— सर्जि कोलोडियाज़नी

Answer 1

1. पाठ फ़ाइल एक नियमित फ़ाइल होनी चाहिए? उपरोक्त अंश में यह स्पष्ट रूप से नहीं कहा गया है कि फ़ाइल एक नियमित फ़ाइल होनी चाहिए

   नहीं; अंश भी विशेष रूप से एक संभावित पाठ फ़ाइल के रूप में मानक इनपुट नोट करता है। अन्य मानक उपयोगिताओं, जैसे कि make, विशेष रूप से एक पाठ फ़ाइल के रूप में चरित्र विशेष फ़ाइल का उपयोग करें ।/dev/null

2. क्या एक फ़ाइल को एक पाठ फ़ाइल माना जा सकता है यदि केवल एक वर्ण और एक वर्ण होता है (यानी, एक एकल वर्ण जिसे एक नई पंक्ति के साथ समाप्त नहीं किया जाता है)?

   वह चरित्र एक <newline> होना चाहिए, या यह एक पंक्ति नहीं है , और इसलिए यह फ़ाइल एक पाठ फ़ाइल नहीं है। एक फाइल जिसमें बाइट 0 ए है, एक सिंगल-लाइन टेक्स्ट फाइल है। एक खाली लाइन एक वैध लाइन है।

3. उपरोक्त अंश में, यह "लाइनों" का संदर्भ देता है। मुझे उनके नाम में लाइन के साथ चार परिभाषाएँ मिलीं: "खाली लाइन", "डिस्प्ले लाइन", "अधूरी लाइन" और "लाइन"। क्या मुझे यह अनुमान लगाना चाहिए कि "खाली", "प्रदर्शन" और "अपूर्ण" के अपने चूक के कारण उनका मतलब "रेखा" है?

   यह वास्तव में एक अनुमान नहीं है, यह सिर्फ यह कहता है। शब्द "लाइन" को एक संदर्भ-उपयुक्त परिभाषा दी गई है और इसलिए यह बात कर रहा है।

4. क्या मैं सुरक्षित रूप से अनुमान लगा सकता हूं कि यदि कोई फ़ाइल खाली है, तो यह एक पाठ फ़ाइल नहीं है क्योंकि इसमें एक या अधिक वर्ण नहीं हैं?

   एक खाली फ़ाइल में शून्य (या अधिक) लाइनें होती हैं और इस प्रकार एक पाठ फ़ाइल होती है।

5. क्या "शून्य" "शून्य या अधिक लाइनों" में होने का मतलब है कि एक फ़ाइल को अभी भी एक पाठ फ़ाइल माना जा सकता है यदि इसमें एक या एक से अधिक वर्ण शामिल हैं जिन्हें नईलाइन के साथ समाप्त नहीं किया गया है?

   नहीं, ये वर्ण लाइनों में व्यवस्थित नहीं हैं।

6. क्या "शून्य या अधिक रेखाएं" का अर्थ है कि एक बार एक "लाइन" (0 या अधिक वर्णों और एक समाप्ति वाली नई रेखा) खेलने में आती है, कि यह अंतिम पंक्ति के लिए "अपूर्ण रेखा" (एक या अधिक गैर-) होना अवैध हो जाता है एक फ़ाइल के अंत में newline वर्ण)?

   यह अवैध नहीं है , यह सिर्फ एक पाठ फ़ाइल नहीं है। इसके लिए दी जाने वाली पाठ फ़ाइल की आवश्यकता वाली उपयोगिता यदि उस फ़ाइल की जगह दी जाए तो प्रतिकूल व्यवहार कर सकती है ।

7. क्या "कोई भी [कोई रेखा] {LINE_MAX} बाइट्स को लंबाई में पार नहीं कर सकती है, जिसमें नई लाइन वर्ण भी शामिल है" का अर्थ है कि किसी पाठ फ़ाइल में दिए गए "लाइन" में अनुमत वर्णों की संख्या तक सीमित है

   हाँ।

यह परिभाषा केवल कुछ सीमाएं निर्धारित करने की कोशिश कर रही है जो एक पाठ-आधारित उपयोगिता ( उदाहरण के लिएgrep ) निश्चित रूप से स्वीकार करेंगे - अधिक कुछ नहीं। वे चीजों को अधिक उदारता से स्वीकार करने के लिए स्वतंत्र हैं, और अक्सर वे व्यवहार में करते हैं। उन्हें एक पंक्ति को संसाधित करने के लिए एक निश्चित आकार के बफर का उपयोग करने की अनुमति है, यह मानने के लिए कि एक नईलाइन पूर्ण होने से पहले दिखाई देती है, और इसी तरह। आप चीजों में बहुत अधिक पढ़ रहे होंगे।

Comments

क्या आप बिंदु 2 के बारे में निश्चित हैं? मानक स्पष्ट रूप से " 0 या अधिक लाइनें" बताता है । तो printf "a" > fileउस परिभाषा के अनुसार एक टेक्स्ट फ़ाइल बनाएंगे। 4 का आपका उत्तर 2 और 5 के आपके उत्तरों का खंडन करता प्रतीत होता है, जैसा कि आप सुझाव देते हैं कि touch fileपाठ फ़ाइल बनाते समय printf "a" > fileऐसा नहीं होता है।

— terdon

@terdon: मुझे माइकल के उत्तर में कोई विरोधाभास नहीं दिखता। मूल रूप से, वह यह कहता हुआ प्रतीत होता है कि POSIX टेक्स्ट फ़ाइल वह फ़ाइल है जिसकी सामग्री regexp से मेल खाती है (.{0,M}\n)*( अनुमानित रूप से एंकर और दोनों सिरों पर), जहां \nएक नई रेखा से मेल खाता है और .किसी भी वर्ण से मेल खाता है जो एक नई Mरेखा नहीं है, और संख्यात्मक मान के लिए एक प्लेसहोल्डर है LINE_MAX -1। विशेष रूप से, इसका तात्पर्य यह है कि एक खाली फ़ाइल शून्य रेखाओं से युक्त एक मान्य पाठ फ़ाइल है, लेकिन किसी भी गैर-रिक्त पाठ फ़ाइल को एक नई पंक्ति में समाप्त होना चाहिए (क्योंकि अन्यथा इसमें एक अधूरी रेखा होगी, और एक अधूरी रेखा एक रेखा नहीं है )।

— इल्मरी करोनें

@ मिचेल होमर नियमित फ़ाइल की बात करते हैं, क्या इसके अलावा अन्य उदाहरण हैं / देव / अशक्त? यह वास्तव में एक पाठ फ़ाइल नहीं है क्योंकि इसमें एक या अधिक अशक्त अक्षर हैं।

— हेरोल्ड फिशर

@HaroldFischer /dev/nullएक खाली फ़ाइल है। आप की सोच रहे हैं /dev/zero।

— माइकल होमर

@ हेरोल्डफिशर, नहीं, /dev/nullखाली के रूप में पढ़ता है, क्योंकि जब आप इसे पढ़ते हैं तो आपको कोई डेटा नहीं मिलता है। मुझे यकीन नहीं है कि यह गैर-नियमित फ़ाइलों पर विचार करने के लिए बहुत मायने रखता है, क्योंकि उनमें से कई प्रकृति में गतिशील हैं। इसमें पाइप, सॉकेट, चार डिवाइस शामिल हैं, जो मूल रूप से किसी अन्य इकाई से / के लिए केवल परिवहन इंटरफेस हैं। वे डेटा का कोई स्थिर सेट नहीं रखते हैं, इसलिए यह फ़ाइल के गुणों के बजाय स्थानांतरित किए गए डेटा के गुणों पर विचार करने के लिए अधिक समझदार होगा ।

— ilkachachu २ '

Answer 2

POSIX द्वारा परिभाषित:

हां, एक पाठ फ़ाइल है (मूल रूप से):

एक फ़ाइल जिसमें वर्ण शून्य या अधिक लाइनों में व्यवस्थित होते हैं।

इस परिभाषा को शामिल करना भी उपयोगी होगा:

3.92 चरित्र स्ट्रिंग

पहले नल बाइट सहित और द्वारा समाप्त किए गए वर्णों का एक सन्निहित अनुक्रम।

3.195 अधूरी रेखा

फ़ाइल के अंत में एक या अधिक गैर-<newline> वर्णों का एक क्रम।

3.206 लाइन

शून्य या अधिक गैर- <newline> वर्णों के साथ-साथ एक समाप्ति <newline> वर्ण का क्रम।

3.243 न्यूलाइन कैरेक्टर (<newline>)

एक चरित्र जो आउटपुट स्ट्रीम में इंगित करता है कि छपाई अगली पंक्ति की शुरुआत में शुरू होनी चाहिए। यह सी भाषा में '\ n' द्वारा निर्दिष्ट चरित्र है। यह अनिर्दिष्ट है कि क्या यह चरित्र अगली पंक्ति के लिए आंदोलन को पूरा करने के लिए सिस्टम द्वारा एक आउटपुट डिवाइस को प्रेषित सटीक अनुक्रम है।

3.247 एनयूएल

सभी बिट्स वाला एक चरित्र शून्य पर सेट है।

ध्यान दें कि "टेक्स्ट फ़ाइल" में NUL बाइट्स नहीं होंगे ।

---

इसलिए:

1. पाठ फ़ाइल एक नियमित फ़ाइल होनी चाहिए?
   नहीं, यह होने की आवश्यकता नहीं है। एक "टेक्स्ट फ़ाइल" को परिभाषित किया जाता है कि इसमें क्या पढ़ा जाता है। यदि किसी फ़ाइल में "शून्य या अधिक लाइनें हैं" तो यह एक पाठ फ़ाइल है। कुछ फ़ाइल, जैसे /dev/stdin, एक पाठ फ़ाइल हो सकती है यदि एक बार में पढ़ी जाती है और अगली बार पढ़ने पर नहीं।
2. क्या एक फ़ाइल को एक पाठ फ़ाइल माना जा सकता है यदि केवल एक वर्ण और एक वर्ण हो…?
   नहीं, यह एक अधूरी रेखा है (3.195)।
   एक टेक्स्ट फ़ाइल में केवल गैर- "अपूर्ण लाइनें" होंगी।
3. क्या मुझे यह अनुमान लगाना चाहिए कि उनका मतलब "लाइन" है ...?
   हाँ तुम्हें करना चाहिए।
4. क्या मैं सुरक्षित रूप से यह पता लगा सकता हूं कि यदि कोई फ़ाइल खाली है, तो यह पाठ फ़ाइल नहीं है ...?
   नहीं, एक खाली फ़ाइल (शून्य वर्ण) एक मान्य "टेक्स्ट फ़ाइल" है।
   ऊपर से: … शून्य या अधिक रेखाएँ… । शून्य लाइनें (शून्य वर्ण) एक मान्य "टेक्स्ट फ़ाइल" है।
5. ... एक पाठ फ़ाइल पर विचार किया जाता है यदि इसमें एक या एक से अधिक वर्ण होते हैं जो नईलाइन के साथ समाप्त नहीं होते हैं?
   नहीं, एक "अपूर्ण रेखा" नहीं (तकनीकी रूप से) एक वैध "रेखा"।

6. क्या "शून्य" "शून्य या अधिक लाइनों" में होने का मतलब है कि एक फ़ाइल को अभी भी एक पाठ फ़ाइल माना जा सकता है यदि इसमें एक या एक से अधिक वर्ण शामिल हैं जिन्हें नईलाइन के साथ समाप्त नहीं किया गया है?
   नहीं, एक अधूरी रेखा "रेखा" नहीं है। एक टेक्स्ट फ़ाइल में अधूरी लाइनें नहीं होंगी।

7. ... पाठ फ़ाइल में किसी भी "लाइन" में अनुमत वर्णों की संख्या तक सीमित है ...?
   हां, {LINE_MAX} बाइट्स (वर्णों के विपरीत) से अधिक किसी भी मान्य "टेक्स्ट फ़ाइल" की किसी भी पंक्ति में अनुमति नहीं दी जाएगी।
   {LINE_MAX} का मान फ़ाइल में दिया गया है <limit.h>
   ( C में संवेदी रेखा बफर आकार भी पढ़ें ? ::

   {LINE_MAX}
   जब तक अन्यथा उल्लेख नहीं किया जाता है, तब उपयोगिता की इनपुट लाइन (या तो मानक इनपुट या किसी अन्य फ़ाइल) की बाइट्स में अधिकतम लंबाई, जब उपयोगिता को टेक्स्ट फ़ाइलों को संसाधित करने के रूप में वर्णित किया जाता है। लंबाई में अनुगामी के लिए कमरा शामिल है।
   न्यूनतम स्वीकार्य मूल्य: {_POSIX2_LINE_MAX}

   GNU आधारित प्रणाली के लिए कोई सीमा निर्धारित नहीं है (स्मृति को छोड़कर) :

   मैक्रो: int LINE_MAX
   सबसे बड़ी टेक्स्ट लाइन जो टेक्स्ट-ओरिएंटेड POSIX.2 उपयोगिताओं का समर्थन कर सकती है। (यदि आप इन उपयोगिताओं के GNU संस्करणों का उपयोग कर रहे हैं, तो उपलब्ध वर्चुअल मेमोरी द्वारा लागू किए जाने के अलावा कोई वास्तविक सीमा नहीं है, लेकिन कोई तरीका नहीं है कि लाइब्रेरी आपको यह बता सके।)

   यह posix_lim.h2048 (कम से कम 64 बिट लिनक्स जीएनयू सिस्टम के लिए) में परिभाषित किया गया लगता है :

   $ grep -ri 'POSIX2_LINE_MAX' /usr/include/ 
   
   /usr/include/x86_64-linux-gnu/bits/xopen_lim.h:#define NL_LANGMAX       _POSIX2_LINE_MAX
   /usr/include/x86_64-linux-gnu/bits/posix2_lim.h:#define _POSIX2_LINE_MAX                2048
   /usr/include/x86_64-linux-gnu/bits/posix2_lim.h:#define LINE_MAX                _POSIX2_LINE_MAX
   

   यह, POSIX उपयोगिता गेटकॉफ़ का उपयोग करके भी पाया जा सकता है :

   $ getconf LINE_MAX
   2048
   

संबंधित: टेक्स्ट फ़ाइलों को एक नई पंक्ति के साथ क्यों समाप्त होना चाहिए?

Comments

यह उत्तर अधिकतर सही है, लेकिन "एक पाठ फ़ाइल एक नियमित फ़ाइल होनी चाहिए" का सही उत्तर नहीं है । किसी भी तरह की फाइल एक टेक्स्ट फाइल हो सकती है, यह सामग्री की बात है, फाइल का प्रकार अप्रासंगिक है। fileउपयोगिता केवल विशेष फ़ाइलों के लिए फ़ाइल प्रकार रिपोर्ट करती है, लेकिन है कि बस कैसे उपयोगिता काम करता है, फायदा नहीं है file - <…या (लिनक्स) file -s …एक विशेष फ़ाइल के लिए फ़ाइल की सामग्री पर अपने शोध प्रणालियों को देखने के लिए। एक विशेष फ़ाइल में आपके द्वारा खोले जाने पर हर बार अलग-अलग सामग्री हो सकती है, इसलिए यह हर बार पाठ फ़ाइल हो सकती है। /dev/nullहमेशा एक पाठ फ़ाइल होती है क्योंकि इसकी सामग्री हमेशा एक पाठ फ़ाइल होती है।

— गिल्स एसओ- बुराई को रोकें '27

grepफ़ाइलों पर उपयोग करने के बजाय , आप getconfसिस्टम कॉन्फिडेंस वैल्यूज़ को प्राप्त करने के लिए उपयोग कर सकते हैं getconf LINE_MAX, जो कि मेरे सिस्टम (Ubuntu 16.04) पर 2048 (बाइट्स) देता है।

— हेमेयेल

मैं उस फ़ाइल को ढूंढना चाहता था जहां चर को परिभाषित किया गया था, इस प्रकार grep आवश्यक था, और काम किया (काफी जल्दी)। लेकिन हां, getconfकॉन्फ़िगरेशन के वर्तमान मूल्य को पढ़ने की अनुमति देता है।

— इसहाक