POSIX अनिवार्य उपयोगिताओं को शेल में क्यों नहीं बनाया गया है?


45

इस प्रश्न का उद्देश्य एक विशेष कंप्यूटिंग समस्या को हल करने के लिए नहीं, एक जिज्ञासा का जवाब देना है। सवाल यह है: POSIX अनिवार्य उपयोगिताओं को आमतौर पर शेल कार्यान्वयन में क्यों नहीं बनाया गया है?

उदाहरण के लिए, मेरे पास एक स्क्रिप्ट है जो मूल रूप से कुछ छोटी पाठ फ़ाइलों को पढ़ती है और जांचती है कि वे ठीक से प्रारूपित हैं, लेकिन स्ट्रिंग की हेरफेर की एक महत्वपूर्ण मात्रा के कारण, मेरी मशीन पर इसे चलाने में 27 सेकंड लगते हैं। यह स्ट्रिंग हेरफेर विभिन्न उपयोगिताओं को कॉल करके हजारों नई प्रक्रियाएं बनाता है, इसलिए धीमापन। मैं बहुत विश्वास है कि अगर उपयोगिताओं में से कुछ में, अर्थात् का निर्माण किया गया हूँ grep, sed, cut, tr, और expr, तो स्क्रिप्ट एक दूसरे में चला जाएगा या उससे कम (सी में मेरे अनुभव के आधार पर)।

ऐसा लगता है कि इन उपयोगिताओं के निर्माण में बहुत सारी स्थितियाँ होंगी, जो शेल स्क्रिप्ट में एक समाधान के स्वीकार्य प्रदर्शन के बीच अंतर कर पाएंगी या नहीं।

जाहिर है, एक कारण यह है कि इन उपयोगिताओं को बनाने के लिए नहीं चुना गया था। हो सकता है कि सिस्टम स्तर पर उपयोगिता का एक संस्करण होने से उस उपयोगिता के कई असमान संस्करण होने से बचा जा सकता है जो विभिन्न गोले द्वारा उपयोग किया जा रहा है। मैं वास्तव में कई नई प्रक्रियाओं को बनाने के ओवरहेड को रखने के लिए कई अन्य कारणों के बारे में नहीं सोच सकता हूं, और पोसिक्स उन उपयोगिताओं के बारे में पर्याप्त रूप से परिभाषित करता है कि यह अलग-अलग कार्यान्वयन के लिए एक समस्या की तरह प्रतीत नहीं होता है, इसलिए जब तक वे प्रत्येक POSIX नहीं हैं। आज्ञाकारी। कम से कम उतनी बड़ी समस्या नहीं है जितनी कि इतनी सारी प्रक्रियाएँ होने की अक्षमता।


15
यदि 27 सेकंड बहुत धीमा है तो आप पायथन, पर्ल या कुछ अन्य अर्ध-संकलित भाषा का उपयोग कर सकते हैं। वैकल्पिक रूप से अपनी स्क्रिप्ट के धीमे भागों को पोस्ट करें और सुधारों के लिए कहें। यह हो सकता है कि आप तीन या चार कमांड का उपयोग कर रहे हों, जहां एक (तेजी से एक) कर सकते हैं।
रोइमा

8
शेल वास्तव में भारी शुल्क वाले कार्यों के लिए नहीं बनाए गए थे, दुर्भाग्य से और दुनिया बहुत बार बदल गई है जब आप सिर्फ शेल स्क्रिप्ट के साथ दूर हो सकते हैं। मैं रोएमा के साथ सहमत हूं - हर उचित sysadmin को अजगर या पर्ल के लिए जाना चाहिए और शेल को सब कुछ संभालने की उम्मीद नहीं करनी चाहिए
Sergiy Kolodyazhnyy

16
शेल का प्राथमिक उद्देश्य अन्य कार्यक्रमों को चलाना है, न कि सीधे डेटा में हेरफेर करना। इन वर्षों में, कुछ बाहरी कार्यक्रमों या उनके द्वारा प्रदान की गई विशेषताएं (ग्लोबिंग, अंकगणित printf, आदि) को शेल में शामिल किया गया है जब उन्हें पर्याप्त उपयोगी माना गया था।
१ner

8
यदि आप अपनी स्क्रिप्ट को codereview.stackexchange.com पर पोस्ट करते हैं, तो मुझे यकीन है कि समीक्षक आपकी स्क्रिप्ट को तेज करने के लिए कुछ सुझाव दे सकते हैं (या कम से कम यह इंगित करें कि इसे शेल के बजाय पायथन / आदि में क्यों लिखा जाना चाहिए)।
चेप्टर

5
@Kyle: awkPOSIX में एक अनिवार्य उपयोगिता (जो है, बहुत तेजी से) स्क्रिप्ट को लागू करने कि आप अन्यथा का उपयोग कर लागू हो सकता है, और विशेष रूप से अच्छी तरह से अनुकूल है sed, cut, tr, grep, और exprएक खोल स्क्रिप्ट में।
नाममात्र पशु

जवाबों:


11

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

शेल प्रोटोटाइपिंग का पहला स्तर है, यदि आप शेल के साथ अवधारणा को साबित कर सकते हैं, तो एक बेहतर स्क्रिप्टिंग भाषा पर जाएं जो अधिक सीमा की जाँच कर सकती है जो शेल की एकड़ ले जाएगी।

एक यूनिक्स ओएस में कई छोटे कार्यक्रमों को शामिल करने की उम्मीद की जाती है जो अच्छी तरह से परिभाषित कार्य करते हैं जो एक बड़ी तस्वीर बनाते हैं। यह एक अच्छी बात है क्योंकि यह बड़े कार्यक्रमों का संकलन करता है। उदाहरण के लिए, qmail पर एक नज़र डालें और Sendmail के साथ तुलना करें। qmail कई कार्यक्रमों से बना है:

http://www.nrg4u.com/qmail/the-big-qmail-picture-103-p1.gif

नेटवर्क डेमन को उजागर करने से आपको कतार प्रबंधक का शोषण करने में मदद नहीं मिलेगी।


ओपी ने विशेष रूप से कोड की गति में सुधार के लिए सुझाव नहीं मांगे। सवाल यह था कि कुछ उपयोगिताओं को बिल्ट-इन cdया जैसे नहीं बनाया गया है pwd
स्टीफन सी

4
सच। इसका उत्तर अखंड और संकलित के बीच के अंतर को व्यक्त करना और इस पक्ष में एक कारण दिखाना था।
एड नेविल

संबंधित: askubuntu.com/a/291926/11751
एक CVn

1
@StephenC cdएक बिलिन है - और यह वास्तव में होना है, क्योंकि एक उपप्रकार में कार्यशील निर्देशिका को बदलने से मूल प्रक्रिया प्रभावित नहीं होती है।
जोनास

67

POSIX अनिवार्य उपयोगिताओं को शेल में क्यों नहीं बनाया गया है?

क्योंकि POSIX आज्ञाकारी होने के लिए, स्टैंडअलोन कमांड के रूप में अधिकांश उपयोगिताओं को प्रदान करने के लिए एक सिस्टम 1 की आवश्यकता होती है ।

उनके निर्मित होने का अर्थ यह होगा कि उन्हें दो अलग-अलग स्थानों में मौजूद होना चाहिए, शेल के अंदर और उसके बाहर। बेशक, बिलिन में शेल स्क्रिप्ट आवरण का उपयोग करके बाहरी संस्करण को लागू करना संभव होगा, लेकिन यह उपयोगिताओं को कॉल करने वाले गैर शेल अनुप्रयोगों को नुकसान पहुंचाएगा।

ध्यान दें कि बिजीबॉक्स ने आपके द्वारा सुझाए गए मार्ग को आंतरिक रूप से कई कमांडों को लागू करने और खुद के लिए लिंक का उपयोग करके स्टैंडअलोन वेरिएंट प्रदान किया। एक समस्या यह है कि कमांड सेट काफी बड़ा हो सकता है, कार्यान्वयन अक्सर मानक के एक सबसेट होते हैं इसलिए अनुपालन नहीं होते हैं।

ध्यान दें कि कम से कम ksh93, bashऔर zshसाझा पुस्तकालयों से बिलिन को गतिशील रूप से लोड करने के लिए चल रहे शेल के लिए कस्टम तरीके प्रदान करके आगे बढ़ें। तकनीकी रूप से, कुछ भी नहीं तो सभी पॉसिट उपयोगिताओं को कार्यान्वित करने और बिल्डिन के रूप में उपलब्ध कराने से रोकता है।

अंत में, नई प्रक्रियाएं पैदा करना आधुनिक OSes के साथ काफी तेज ऑपरेशन बन गया है। यदि आप वास्तव में प्रदर्शन के मुद्दे से प्रभावित हैं, तो आपकी स्क्रिप्ट को तेज़ी से चलाने के लिए कुछ सुधार हो सकते हैं।

1 POSIX.1-2008

हालाँकि, सभी मानक उपयोगिताओं , जिसमें तालिका में नियमित रूप से निर्मित इन्स शामिल हैं, लेकिन विशेष अंतर्निहित यूटिलिटीज में वर्णित विशेष बिल्ट-इन को इस तरीके से लागू नहीं किया जाएगा , ताकि उन्हें क्रियान्वित परिवार के माध्यम से एक्सेस किया जा सके POSIX.1-2008 के सिस्टम इंटरफेसेस वॉल्यूम में परिभाषित कार्यों के रूप में कार्य किया जा सकता है और इसे सीधे उन मानक उपयोगिताओं द्वारा लागू किया जा सकता है जिन्हें इसकी आवश्यकता होती है (env, find, nice, nohup, time, xargs)।


4
यह सही उत्तर है, लेकिन मैं सिर्फ इतना कहना चाहूंगा कि चूंकि इन उपयोगिताओं का इंटरफ़ेस आम तौर पर वैसे भी स्टड / स्टडआउट के माध्यम से होता है, भले ही उनमें से हर एक को एक अंतर्निहित दिनचर्या के रूप में लागू किया गया हो, लेकिन इसे प्रभावी रूप से अभी भी आवश्यकता होगी खुद को कांटा बनाने और वैसे भी एक पाइप लाइन में प्रत्येक कमांड के लिए पाइप बनाने के लिए, इसलिए केवल मामूली लाभ होगा
चुनको

2
@Chunko हाँ। हालाँकि, सबहेल्ड कांटे / निष्पादित प्रक्रियाओं की तुलना में हल्के हैं।
जॉलीग्रे

3
@slebetman आपको मेरी बात याद आ रही है। सबस्क्राइब न तो थ्रेड होते हैं और न ही निष्पादित प्रक्रियाएँ, चाहे वे लिनक्स पर चल रहे हों या नहीं। सबस्क्राइब सिर्फ उनके माता-पिता के क्लोन हैं, जिनके द्वारा fork नहीं बनाया गया है exec; forkआजकल की तुलना में बहुत हल्का ऑपरेशन है exec
8

3
मैंने noforkव्यस्त बॉक्स बिल्डरों को बिल्डरों की तुलना में 10x कम ओवरहेड के आदेश पर मापा noexec, जिसके बदले में एक अलग बाइनरी के कांटा + निष्पादन की तुलना में ~ 5x कम ओवरहेड था। Unix.stackexchange.com/a/274322/29483 के अनुसार परिभाषाएँ यह दिलचस्प है कि बिजीबॉक्स noforkसब कुछ नहीं करता है, हालांकि मुझे पता है कि कुछ बिजीबॉक्स कोड को मेमोरी की सफाई नहीं करने से छोटा किया जाता है, और बस एक अल्पकालिक प्रक्रिया होने पर निर्भर करता है।
sourcejedi

1
@ जेलीग्रे: लाइनक्स पर एक कांटा एक प्रक्रिया बनाता है। वह बिंदु जो आप शायद याद कर रहे हैं कि लिनक्स पर वे प्रक्रियाओं को इतना अनुकूलित कर चुके हैं कि डेवलपर्स ने निर्धारित किया है कि कुछ और अधिक हल्के बनाने से अधिक लाभ नहीं है। मूल रूप से linux में एक प्रक्रिया एक थ्रेड की तरह हल्की होती है।
स्लीपबेटमैन

9

से मार संदर्भ मैनुअल ,

अंतर्निहित उपयोगिताओं को अलग-अलग उपयोगिताओं के साथ प्राप्त करने के लिए असंभव या असुविधाजनक कार्यक्षमता को लागू करना आवश्यक है।

जैसा कि मुझे यकीन है कि आपने सुना है, UNIX दर्शन कई अनुप्रयोगों पर बहुत अधिक निर्भर करता है जिनकी सभी सीमित कार्यक्षमता होती है। प्रत्येक अंतर्निहित में एक बहुत अच्छा कारण है कि यह क्यों बनाया गया है। बाकी सब कुछ नहीं है। मुझे लगता है कि सवालों की एक और अधिक दिलचस्प वर्ग के, लाइनों के साथ कि "क्यों वास्तव में है pwd निर्मित?"


2
एक शब्द में: प्रतिरूपकता
पेश्के

2
/ बिन / pwd मौजूद है। मुझे लगता cdहै कि यहां एक बेहतर उदाहरण होगा जो एक अलग उपकरण के रूप में लागू करना असंभव है।
Oskar Skog

1
@OskarSkog वह बात थी। cdमें बनाया जाना है, pwdनहीं करता है। तो bashकार्यान्वयनकर्ताओं ने इसे शामिल करने के लिए क्यों चुना?
कलंक हेमर

1
... जो unix.stackexchange.com/questions/145479 द्वारा कवर किया गया है ।
जेडीबीपी

@StigHemmer /bin/bashमौजूद नहीं है, लेकिन यह अभी भी एक बिलिन है। बिल्डरों
स्टीफन सी

8

एटी एंड टी के लोगों ने खुद से भी यही बात पूछी

यदि आप एटी एंड टी सॉफ्टवेयर टूलकिट के इतिहास को देखते हैं (वर्तमान में कोर टीम के जाने के बाद से जीथुब पर निष्क्रिय पड़े हुए हैं), तो ठीक यही उन्होंने एटी एंड टी कोर्न शेल उर्फ ​​ksh93 के साथ किया।

प्रदर्शन हमेशा ksh93 अनुरक्षकों के लिए प्रेरणा का हिस्सा था, और जब ksh का निर्माण आप गतिशील रूप से भरी हुई पुस्तकालयों के रूप में कई सामान्य POSIX उपयोगिताओं का निर्माण करने के लिए चुन सकते हैं। इन आदेशों को निर्देशिका नाम की तरह बांधने से /opt/ast/bin, आप उस निर्देशिका के नाम के स्थान के आधार पर कमांड के किस संस्करण का उपयोग कर सकते हैं $PATH

उदाहरण:

cat chmod chown cksum cmp cp cut date expr fmt head join ln
mkdir mkfifo mktemp mv nl od paste rm tail tr uniq uuencode wc

पूरी सूची github ast रिपॉजिटरी में पाई जा सकती है।

ध्यान दें कि अधिकांश अस्त्र उपकरण के अपने स्वयं के सिद्ध होते हैं और अधिक सामान्य गनु के कार्यान्वयन से दृढ़ता से भिन्न होते हैं। एटी एंड टी रिसर्च टीम ने आधिकारिक मानकों का पालन किया, जो कोड साझा नहीं कर पाने पर इंटरऑपरेबिलिटी हासिल करने का तरीका था।


6

इसलिए हमने हर विशिष्ट इच्छा को पूरा करने के लिए मूल उपकरण के अनुकूलन में मार्शल संसाधन नहीं बनाए। मुझे लगता है कि हमें यह समझाने की आवश्यकता है कि इस विशिष्ट इच्छा को लागू करने में कितना खर्च होगा।

POSIX उपयोगिताओं के बारे में पर्याप्त रूप से परिभाषित करता है कि यह अलग-अलग कार्यान्वयन के लिए एक समस्या की तरह नहीं लगता है।

यह एक बुरी धारणा है :-P

पोस्ट-पॉसिक्स सिस्टम अच्छे कारणों के लिए अधिक शक्तिशाली और सुविधाजनक बनना जारी रखते हैं; एक मानक तथ्य के रूप में यह वास्तव में कभी नहीं पकड़ता है।

उबंटू ने स्क्रिप्ट के लिए एक स्ट्रिप-डाउन POSIX शेल पर स्विच करने का प्रयास शुरू किया, ताकि पुराने सिस्टम V init बूट प्रक्रिया को ऑप्टिमाइज़ किया जा सके। मैं यह नहीं कह रहा हूं कि यह विफल रहा, लेकिन इसने कई बगों को ट्रिगर किया, जिन्हें साफ करना था: "बशीज़", स्क्रिप्ट जो /bin/shयह मानते हुए कि bashसुविधाएँ उपलब्ध थीं, के तहत भाग गया ।

POSIX sh एक अच्छी सामान्य-प्रयोजन प्रोग्रामिंग भाषा नहीं है। इसका प्राथमिक उद्देश्य एक इंटरैक्टिव शेल के रूप में अच्छी तरह से काम करना है। जैसे ही आप अपने आदेशों को एक स्क्रिप्ट में सहेजना शुरू करते हैं, ध्यान रखें कि आप ट्यूरिंग टारपीट से संपर्क करें । उदाहरण के लिए, सामान्य पाइपलाइन के बीच में विफलताओं का पता लगाना संभव नहीं है । bashइसके लिए जोड़ा गया set -o pipefailहै, लेकिन यह POSIX में नहीं है।

इसी तरह की उपयोगी लेकिन अस्वास्थ्यकर सुविधाएँ लगभग हर उपयोगिता की तुलना में अधिक जटिल हैं true

आप जिस कार्य की रूपरेखा तैयार करते हैं, उसके वर्ग के लिए आप Awk, Perl और आजकल Python को एक कठिन रेखा खींच सकते हैं। विभिन्न उपकरण बनाए गए, और स्वतंत्र रूप से विकसित हुए। क्या आप उम्मीद करेंगे कि GNU Awk को एक libutilposixextended में शामिल किया जाएगा?

मैं यह नहीं कह रहा हूं कि अब हमारे पास एक सार्वभौमिक रूप से बेहतर दृष्टिकोण है जो मैं आपको इंगित कर सकता हूं। मेरे पास पायथन के लिए एक नरम स्थान है। अवाक आश्चर्यजनक रूप से शक्तिशाली है, हालांकि मैं कुछ सुविधाओं से निराश हूं जो कि जीएनयू अवाक के लिए विशिष्ट है। लेकिन मुद्दा यह है कि बड़ी संख्या में तार को व्यक्तिगत रूप से संसाधित करना (संभवतः फ़ाइलों की रेखाओं से) PIXIX शेल का डिज़ाइन लक्ष्य नहीं था।


मुझे आश्चर्य है कि अगर किसी शेल के साथ कोई कठिनाई होगी जो यह मान लेगा कि स्थानों की एक विन्यास सूची से निष्पादित किसी भी कमांड को एक अंतर्निहित मामलों के रूप में माना जाएगा जहां शेल कमांड के बारे में सब कुछ समझ गया है? यदि कोई स्क्रिप्ट करता है cat -@fnord fooतो शेल को यह तय करना चाहिए कि चूंकि यह नहीं जानता है कि -@वास्तविक कमांड को लागू करने के लिए इसका क्या अर्थ है, लेकिन यह देखते हुए cat <foo >barकि शेल को किसी अन्य प्रक्रिया को स्पॉन करने की आवश्यकता नहीं है।
सुपरकैट

1
@ सुपरकंप्यूट जटिलता।
sourcejedi

2

यह भी सवाल है: आप इसे किस शेल में बनाएंगे?

अधिकांश यूनिक्स / लिनक्स सिस्टम में कई अलग-अलग गोले होते हैं जो स्वतंत्र रूप से विकसित होते हैं (sh / bash / korn / ???)। यदि आप उपकरण को शेल में बनाते हैं, तो आप प्रत्येक शेल के लिए इन उपकरणों के एक अलग कार्यान्वयन के साथ समाप्त होंगे। यह ओवरहेड का कारण होगा, और आप उदाहरण grep के लिए अलग-अलग सुविधाओं / बग के साथ समाप्त हो सकते हैं, इस बात पर निर्भर करता है कि आपने इसे किस शेल पर आमंत्रित किया था।


zsh इन दिनों कुछ हलकों में काफी लोकप्रिय है। csh / tcsh का ऐतिहासिक रूप से बहुत बड़ा अनुसरण हुआ है, लेकिन मुझे नहीं लगता कि आज आप इसे देख पाते हैं। और कम-ज्ञात गोले का एक पूरा बंडल है ...
एक CVn

प्रतिरूपकता। बिल्डिंस के साथ, आपको उन सभी बिल्डिंग्स में से एक में परिवर्तन किए जाने पर शेल को फिर से स्थापित करने या फिर से स्थापित करने की आवश्यकता होगी।
कैन-नेड_फूड

1

कई ने अच्छी तरह से उत्तर दिया है। मैं केवल उन उत्तरों की प्रशंसा करना चाहता हूं। मुझे लगता है कि UNIX दर्शन यह है कि एक उपकरण को एक काम करना चाहिए और इसे अच्छी तरह से करना चाहिए। यदि कोई एक सभी को शामिल करने के उपकरण बनाने की कोशिश करता है, तो यह विफलता के लिए बहुत अधिक जगह है। इस तरह से कार्यक्षमता को सीमित करना एक उपकरण सेट बनाता है जो विश्वसनीय है।

इसके अलावा, विचार करें कि अगर सेड या ग्रेप जैसी कार्यक्षमता शेल में बनाई गई थी, तो क्या कमांड लाइन से आह्वान करना इतना आसान होगा, जब आप इसे पसंद करेंगे?

बंद करने पर विचार करें, कुछ कार्यक्षमता जो आप BASH में होना चाहते हैं , BASH में है । उदाहरण के लिए, मार में आरई मिलान के लिए क्षमता का उपयोग कर कार्यान्वित किया जाता है = ~ द्विआधारी ऑपरेटर (देखें मैनुअल पृष्ठ में शैल व्याकरण अधिक, विशेष रूप से, के लिए [[]] निर्माण की चर्चा संदर्भ के लिए है, तो )। एक बहुत ही त्वरित उदाहरण के रूप में, मैं 2 हेक्स अंकों के लिए एक फ़ाइल खोज रहा हूँ:

while read line; do
    if [[ $line =~ 0x[[:xdigit:]]{2} ]]; then
        # do something important with it
    fi
done < input_file.txt

जैसा कि सेड-जैसी कार्यक्षमता के लिए, उसी पुरुष पृष्ठ के विस्तार शीर्षक में पैरामीटर विस्तार के अंतर्गत देखें । आप उन चीजों का खजाना देख सकते हैं जो आप कर सकते हैं जो कि सेड की याद दिलाती हैं। मैं अक्सर कुछ प्रतिस्थापन प्रकार को पाठ में बदलने के लिए sed का उपयोग करता हूं। ऊपर की इमारत:

# this does not take into account the saving of the substituted text
# it shows only how to do it
while read line; do
    ${line/pattern/substitution}
done < input_file.txt

हालांकि अंत में, उपरोक्त "से बेहतर" है?

grep -E "[[:xdigit:]]{3}" input_file.txt
sed -e 's/pattern/substitution/' input_file.txt

आखिरी सवाल के खिलाफ एक तर्क unix.stackexchange.com/questions/169716/… के
phk

1

यह, मुझे लगता है, एक ऐतिहासिक दुर्घटना है।

जब यूनिक्स को 1960 के दशक के अंत में और 1970 के दशक की शुरुआत में बनाया गया था, तब कंप्यूटर के पास लगभग उतनी मेमोरी नहीं थी जितनी आज है। यह संभव है, उस समय, शेल बिल्डरों के रूप में इस सभी कार्यक्षमता को लागू करने के लिए, लेकिन स्मृति सीमाओं के कारण, उन्हें कार्यक्षमता की मात्रा को सीमित करना होगा जो वे लागू कर सकते हैं, या स्मृति से बाहर जोखिम और / या स्वैप ट्रैशिंग कर सकते हैं। समस्या।

दूसरी ओर, दिए गए कार्यक्षमता को अलग-अलग कार्यक्रमों के रूप में लागू करके, और एक नई प्रक्रिया शुरू करने के लिए दो आवश्यक सिस्टम कॉल के रूप में संभव के रूप में प्रकाश शुरू करके, वे एक स्क्रिप्टिंग वातावरण बना सकते हैं जिसमें उन समस्याएं नहीं हैं और जो अभी भी उचित रूप से चलती हैं गति।

बेशक, एक बार उन चीजों को अलग-अलग प्रक्रियाओं के रूप में लागू किया जाता है, तो लोग उन्हें उन कार्यक्रमों से शुरू करेंगे जो कि गोले नहीं हैं, और फिर उन्हें ऐसे ही रहना होगा, या अचानक यह सब सॉफ्टवेयर टूटने लगेगा।

यह कहना नहीं है कि आप दो बार कुछ कार्यक्षमता को लागू नहीं कर सकते हैं, और वास्तव में कुछ गोले कुछ कार्यक्षमता को लागू करते हैं जो कि शेल के रूप में एक बाहरी कार्यक्रम माना जाता है; उदाहरण के लिए, बैश echoकमांड को एक बेसिन के रूप में लागू करता है , लेकिन एक ए भी है/usr/bin/echo

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