यदि बॉर्न शेल किसी वितरण में उपलब्ध नहीं है, तो क्या हैशबैंग में बिन / श का उपयोग करना सही है?

Question

आमतौर पर, शेल स्क्रिप्ट में स्क्रिप्ट फ़ाइल की पहली पंक्ति में निम्न टिप्पणी होती है #!/bin/sh:। मेरे द्वारा किए गए शोधों के अनुसार, इसे "हैश बैंग" कहा जाता है और यह पारंपरिक टिप्पणी है। यह टिप्पणी यूनिक्स को सूचित करती है कि यह फ़ाइल निर्देशिका के तहत बॉर्न शेल द्वारा निष्पादित की गई है /bin।

मेरा सवाल उस बिंदु से शुरू होता है। अब तक मैंने इस टिप्पणी को देखा नहीं है #!/bin/bash। यह हमेशा से है #!/bin/sh। हालांकि, उबंटू वितरण में बॉर्न शेल कार्यक्रम नहीं है। उनके पास बॉर्न अगेन शेल (बैश) है।

उस बिंदु में, क्या #!/bin/shउबंटू वितरण में लिखी गई शेल स्क्रिप्ट में टिप्पणी को रखना सही है ?

Comments

AKA

— Shebang

इस सर्वरफॉल्ट प्रश्न के लिए मेरा उत्तर देखें: #! / Bin / sh vs #! / Bin / bash अधिकतम पोर्टेबिलिटी के लिए ।

— गॉर्डन डेविसन

अधिक सामान्यतः कहा जाता हैshebang

— fpmurphy

Answer 1

#!/bin/shसभी यूनिक्स और यूनिक्स जैसे वितरण पर काम करना चाहिए। यह आमतौर पर सबसे पोर्टेबल हैशबैंग के रूप में सोचा जाता है जब तक कि आपकी स्क्रिप्ट POSIX का अनुपालन नहीं करती है। /bin/shशेल को एक ऐसा शेल माना जाता है जो POSIX शेल मानक को लागू करता है, भले ही वास्तविक शेल शेल के रूप में बहाना हो /bin/sh।

---

#!/bin/shआमतौर पर अभी एक लिंक है क्योंकि बॉर्न शेल अब नहीं है। पर कई यूनिक्स प्रणालियों /bin/shके लिए एक लिंक हो जाएगा /bin/kshया /bin/ashकई RHEL आधारित Linux सिस्टम पर, यह करने के लिए एक कड़ी हो जाएगा /bin/bash, हालांकि Ubuntu और कई डेबियन आधारित सिस्टम पर यह करने के लिए एक कड़ी है /bin/dash। सभी गोले, जब आमंत्रित किए जाते हैं sh, तो POSIX संगतता मोड में प्रवेश करेगा।

हैशबैंग एक महत्वपूर्ण प्लेसहोल्डर है, क्योंकि यह अन्य तरीकों की तुलना में बहुत अधिक पोर्टेबिलिटी की अनुमति देता है, इसलिए जब तक आपकी स्क्रिप्ट सख्ती से पॉसिक्स कंप्लेंट है (तनाव महत्व के लिए दोहराया जाता है)।

नोट: जब bashPOSIX मोड में इनवॉइस किया जाता है तो यह अभी भी कुछ गैर-पॉसिक्स चीजों की अनुमति देगा [[, जैसे सरणियाँ, और बहुत कुछ। वे चीजें एक गैर- bashप्रणाली पर विफल हो सकती हैं ।

Comments

"उबंटू पर यह / बिन / डैश के लिए एक कड़ी है" और सामान्य रूप से अन्य डेबियन-आधारित प्रणालियों में। FreeBSD / GhostBSD पर IIRC यह एक सहिष्णुता है /bin/ash।

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

पूरी तरह से पोर्टेबल होने के लिए, शेबंग और (निरपेक्ष) दुभाषिया पथ के बीच एक स्थान रखें। कुछ प्रणालियों के #! /बजाय बस के लिए देखो #!।

— सिमोन रिक्टर

@SimonRichter इसके लिए एक संदर्भ देखना अच्छा होगा।

— Kusalananda

@SergiyKolodyazhnyy FreeBSD पर sh का इंस्टॉल किया गया संस्करण ऐश है और सिमिलर नहीं है।

— रॉब

@ कुसलानंद, हम्म, इस पृष्ठ का कहना है कि यह एक मिथक है, इसलिए इसे शायद अनदेखा किया जा सकता है।

— साइमन रिक्टर

Answer 2

आपने इसे पिछड़ा हुआ पाया है। /bin/shइन दिनों लगभग एक बॉर्न शेल कभी नहीं होता है, और यह तब होता है जब आप एक #! /bin/shधमाके का उपयोग करते हैं तो आपको एक समस्या होती है ।

बोर्न शेल 70 के दशक के अंत में लिखा गया एक शेल था और पिछले थॉम्पसन शेल (जिसे भी कहा जाता है sh) को प्रतिस्थापित किया गया था । 80 के दशक की शुरुआत में, डेविड कॉर्न ने बॉर्न शेल के लिए कुछ एक्सटेंशन लिखे, कुछ बग्स और डिज़ाइन के अजीबपन को ठीक किया (और कुछ को पेश किया) और इसे कॉर्न शेल कहा।

90 के दशक की शुरुआत में, POSIX ने कोर्न शेल के सबसेट के आधार पर sh भाषा को निर्दिष्ट किया और Most 90 सिस्टम ने अब उन्हें /bin/shया तो कॉर्न शेल या शेल विनिर्देशन में बदल दिया है। बीएसडी के मामले में, उन्होंने धीरे-धीरे अपने को बदल दिया /bin/sh, शुरू में (बाद में वे लाइसेंस के कारणों के लिए बॉर्न शेल का उपयोग नहीं कर सके) अल्मक्विस्ट शेल, बोर्न शेल का एक क्लोन जो कुछ ksh एक्सटेंशन के साथ था, इसलिए यह POSIX आज्ञाकारी बन गया।

आज, सभी POSIX प्रणालियों में एक शेल होता है sh(सबसे अधिक बार, लेकिन जरूरी नहीं कि /bin, POSIX उपयोगिताओं के पथ को निर्दिष्ट नहीं करता है) जो कि ज्यादातर POSIX अनुरूप है। यह आमतौर पर या तो ksh88, ksh93, pdksh, bash, ash या zsh² पर आधारित होता है, लेकिन बॉर्न शेल के रूप में नहीं, क्योंकि बॉर्न शेल कभी POSIX कंप्लेंट नहीं था। उन के गोले में से कुछ ( bash, zsh, yashऔर कुछ pdkshडेरिवेटिव एक POSIX शिकायत मोड जब के रूप में लागू करने के लिए सक्षम shऔर कर रहे हैं कम अन्यथा अनुरूप)।

bash(कोर्न शेल का GNU उत्तर) वास्तव में एकमात्र खुला स्रोत शेल है (और एक ही कह सकता है कि वर्तमान में बनाए रखा जा सकता है क्योंकि अन्य आमतौर पर ksh88 पर आधारित होते हैं, जो 90 के दशक के बाद से कोई नई सुविधा नहीं मिली है) जिसे इस रूप में प्रमाणित किया गया है एक POSIX आज्ञाकारी होने के नाते sh(macOS प्रमाणीकरण के भाग के रूप में)।

जब आप #! /bin/sh -शी-बैंग के साथ एक स्क्रिप्ट लिखते हैं , तो आपको एक मानक shसिंटैक्स का उपयोग करना चाहिए (और उस स्क्रिप्ट में उपयोग की जाने वाली उपयोगिताओं के लिए भी मानक सिंटैक्स का उपयोग करना चाहिए यदि आप पोर्टेबल होना चाहते हैं, तो यह केवल शेल नहीं है जो शेल की व्याख्या करते समय शामिल है स्क्रिप्ट), तो यह कोई फर्क नहीं पड़ता कि उस मानक shवाक्यविन्यास दुभाषिया का क्या उपयोग किया जाता है ( ksh, bash...)।

इससे कोई फर्क नहीं पड़ता कि उन गोले के मानक पर एक्सटेंशन हैं जब तक आप उनका उपयोग नहीं करते हैं। यह सी कोड लिखने के लिए है, जब तक आप मानक सी कोड लिखते हैं और एक संकलक (जैसे gcc) या दूसरे के एक्सटेंशन का उपयोग नहीं करते हैं , आपके कोड को संकलक कार्यान्वयन की परवाह किए बिना ठीक संकलित करना चाहिए बशर्ते कि संकलक आज्ञाकारी है।

इधर, अपने साथ #! /bin/shवह-बैंग, अपने मुख्य समस्या वाले सिस्टम होगा /bin/shबॉर्न शैल है कि उदाहरण की तरह मानक सुविधाओं का समर्थन नहीं करता के लिए $((1+1)), $(cmd), ${var#pattern}... में जो मामले आप की तरह काम arounds आवश्यकता हो सकती है:

#! /bin/sh -
if false ^ true; then
  # in the Bourne shell, ^ is an alias for |, so false ^ true returns
  # true in the Bourne shell and the Bourne shell only.
  # Assume the system is Solaris 10 (older versions are no longer maintained)
  # You would need to adapt if you need to support some other system
  # where /bin/sh is the Bourne shell.
  # We also need to fix $PATH as the other utilities in /bin are
  # also ancient and not POSIX compatible.
  PATH=`/usr/xpg6/bin/getconf PATH`${PATH:+:}$PATH || exit
  export PATH
  exec /usr/xpg4/bin/sh "$0" "$@"
  # that should give us an environment that is mostly  compliant
  # to the Single UNIX Specification version 3 (POSIX.2004), the
  # latest supported by Solaris 10.
fi
# rest of the script

वैसे, उबंटू डिफ़ॉल्ट रूप /bin/shसे नहीं bashहै। यह dashइन दिनों, एक शेल है जो नेटबीएसडी पर आधारित है sh, खुद अल्मक्विस्ट शेल पर आधारित है जो ज्यादातर पॉसिक्स अनुपालन है इसके अलावा यह मल्टी-बाइट वर्णों का समर्थन नहीं करता है। Ubuntu और अन्य डेबियन-आधारित सिस्टम पर, आप के बीच चयन कर सकते हैं bashऔर dashके लिए /bin/shके साथ dpkg-reconfigure dash) ⁴ । shडेबियन के साथ भेज दी गई लिपियों को दोनों गोले में समान काम करना चाहिए क्योंकि वे डेबियन नीति मानक (पोसिक्स मानक का एक सुपरसेट) में लिखे गए हैं। आप शायद वे भी मिल जाएगा में काम ठीक zshहै shअनुकरण या bosh(शायद नहीं ksh93है और न ही yashजो एक की जरूरत नहीं है localbuiltin (Debian नीति नहीं बल्कि POSIX) द्वारा अपेक्षित)।

Unix.stackexchange.com पर दायरे की सभी प्रणालियों में sh कहीं न कहीं एक POSIX है। उनमें से अधिकांश के पास एक है /bin/sh(आप बहुत दुर्लभ मिल सकते हैं जिनके पास एक /binनिर्देशिका नहीं है लेकिन आप शायद इस बारे में परवाह नहीं करते हैं), और यह आम तौर पर एक पॉसिक्स shदुभाषिया है (और दुर्लभ मामलों में (गैर-मानक) बॉर्न शेल के बजाय )।

लेकिन shएकमात्र शेल दुभाषिया निष्पादन योग्य है जिसे आप सिस्टम पर ढूंढना सुनिश्चित कर सकते हैं। अन्य गोले के लिए, आप सुनिश्चित कर सकते हैं कि macOS, Cygwin और अधिकांश GNU / Linux वितरण होंगे bash। SYSV व्युत्पन्न OSes (Solaris, AIX ...) में आमतौर पर ksh88, संभवतः ksh93 होगा। OpenBSD, MirOS में pdksh व्युत्पन्न होगा। macOS होगा zsh। लेकिन उसमें से, कोई गारंटी नहीं होगी। इस बात की कोई गारंटी नहीं है कि bashया किसी अन्य गोले को /binया कहीं और स्थापित किया जाएगा (यह आमतौर /usr/local/binपर बीएसडी पर पाया जाता है जब उदाहरण के लिए स्थापित होता है)। और निश्चित रूप से स्थापित किए जाने वाले शेल के संस्करण की कोई गारंटी नहीं है।

ध्यान दें कि #! /path/to/executableयह एक सम्मेलन नहीं है , यह सभी यूनिक्स की तरह गुठली ( डेनिस रिची द्वारा 80 के दशक की शुरुआत में शुरू की गई ) की एक विशेषता है जो एक पहली पंक्ति में दुभाषिया के मार्ग को निर्दिष्ट करके मनमानी फाइलों को निष्पादित करने की अनुमति देता है #!। यह किसी भी निष्पादन योग्य हो सकता है।

जब आप ऐसी फ़ाइल निष्पादित करते हैं, जिसकी पहली पंक्ति शुरू होती है #! /some/file some-optional-arg, तो कर्नेल निष्पादन के /some/fileसाथ समाप्त होता है some-optional-arg, स्क्रिप्ट का मार्ग और तर्क के रूप में मूल तर्क। आप देख सकते हैं कि पहली पंक्ति #! /bin/echo testक्या हो रही है:

$ ./myscript foo
test ./myscript foo

जब आप /bin/sh -इसके बजाय उपयोग करते हैं /bin/echo test, तो कर्नेल निष्पादित होता है /bin/sh - ./myscript foo, इसमें shसंग्रहीत सामग्री कोड की व्याख्या करता है myscriptऔर उस पहली पंक्ति को अनदेखा करता है क्योंकि यह एक टिप्पणी है (शुरुआत के साथ #)।

---

^{¹ संभवतः आज की एकमात्र प्रणाली जहाँ हममें से कोई भी एक /bin/shबॉर्न शेल पर आधारित है, वह सोलारिस है। सोलारिस उन कुछ यूनियनों में से एक है, जिन्होंने पिछड़ी अनुकूलता के लिए बॉर्न शेल रखने का फैसला किया है (पोसिक्स shभाषा पूरी तरह से नहीं है। बॉर्न शेल के साथ पीछे की ओर संगत) और (कम से कम डेस्कटॉप और पूर्ण सर्वर परिनियोजन के लिए) POSIX shकहीं और (में /usr/xpg4/bin/sh, ksh88 पर आधारित) है, लेकिन सोलारिस 11 में बदल गया है जहां /bin/shअब ksh93 है। दूसरे लोग ज्यादातर दोषपूर्ण हैं।}

^{² MacOS / एक्स हुआ करता था की , लेकिन बाद में करने के लिए बदल । यह POSIX कार्यान्वयन के रूप में इस्तेमाल किया जाने वाला प्राथमिक ध्यान नहीं है । इसका मोड मुख्य रूप से स्क्रिप्ट्स में POSIX कोड एम्बेड या कॉल करने में सक्षम है/bin/shzshbashzshshshsourceshzsh}

^{³ हाल ही में, @schily ने POSIX आज्ञाकारी बनने के लिए ओपनसोलारिस शेल (एसवीआर 4 शेल पर आधारित, बॉर्न शेल के आधार पर) को बढ़ाया, कहा जाता है, boshलेकिन मुझे पता नहीं है कि यह अभी तक किसी भी सिस्टम पर उपयोग किया जाता है। इसके साथ ही ksh88यह बॉर्न शेल के कोड के आधार पर एक दूसरा POSIX- अनुरूप शेल बनाता है}

^{4 पुराने संस्करणों में, आप mkshPOSIX lkshअवतार का उपयोग कर सकते हैं । यह मिर्क (पूर्व में MirBSD) शेल पर आधारित pdksh है, जो खुद फोर्सिथ शेल (बॉर्न शेल का एक और पुन: कार्यान्वयन) पर आधारित है)}

Comments

मामूली बात (शेल कोड मिड-आंसर के बारे में): क्या आपको exec sh "$0" "$@"सेट करने के बाद सिर्फ उपयोग नहीं करना चाहिए PATH? shमुझे सही जगह से उठाना चाहिए , मैंने सोचा होगा।

— Kusalananda

@ कुसलानंद, जो काम करना चाहिए, लेकिन अधिक जोखिम भरा है क्योंकि हम एक अंतहीन लूप में समाप्त हो सकते हैं यदि कुछ का एमिस (जैसे गलत अनुमतियों के साथ शट, गेटकॉफ संशोधित ...)। वैसे भी, बाकी सोलारिस 10 के लिए विशिष्ट है, इसलिए हम सामग्री की सामग्री सहित हर चीज को हार्डकोड भी कर सकते हैं $PATH।

— स्टीफन चेज़लस

OSX के लिए कोई प्रशस्ति पत्र अपने POSIX खोल के रूप में ksh का उपयोग कर। इसका डिफ़ॉल्ट शेल tcsh हुआ करता था, लेकिन मुझे याद नहीं है कि बैश का उपयोग विशेष रूप से नहीं किया जा रहा है क्योंकि Korn Shell तब तक खुला स्रोत नहीं था जब तक OSX बाहर नहीं आया

— user151019

@ मार्क, मैंने यह नहीं कहा कि OSX कभी ksh का उपयोग करता है। मैंने कहा कि यह zsh हुआ करता था और उन्होंने bash (bash का एक विशेष निर्माण) पर स्विच किया।

— स्टीफन चेज़लस

@fpmurphy, यदि आप शुरुआती संस्करणों को देखते हैं, तो बैश पहले से ही ksh के साथ साइडिंग कर रहा था, जहाँ ksh बॉर्न शेल के साथ संगत नहीं था। जबकि आपको kash88 के समान फीचर-स्तर पर पहुंचने के लिए bash2 तक इंतजार करना था, bash के पास पहले से ही ksh के कई एक्सटेंशन मौजूद थे $(...), जैसे emacs / vi मोड, tilde / brace expansions (वे जो शुरू में ssh से आते हैं), fc, टाइपसेट, अन्य ,

— ksh-

Answer 3

हां, आप #!/bin/shएक स्क्रिप्ट में उपयोग कर सकते हैं क्योंकि /bin/sh(उम्मीद है) ऐसी प्रणालियों के लिए प्रदान किया जाता है, आमतौर पर किसी प्रकार के लिंक के माध्यम से जो एक bashव्यवहार की तरह (अधिक या कम) करता है sh। यहाँ, उदाहरण के लिए एक Centos7 प्रणाली है, लिंक है कि shकरने के लिए bash:

-bash-4.2$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Dec  4 16:48 /bin/sh -> bash
-bash-4.2$ 

#!/bin/bashयदि आप bashकेवल उस प्रणाली के लिए स्क्रिप्ट लिख रहे हैं और bashसुविधाओं का उपयोग करना चाहते हैं तो आप इसका उपयोग भी कर सकते हैं । हालाँकि, ऐसी स्क्रिप्ट पोर्टेबिलिटी की समस्या से ग्रस्त होंगे, उदाहरण के लिए OpenBSD पर जहाँbash केवल स्थापित किया गया है अगर व्यवस्थापक इसे स्थापित करने के लिए परेशानी लेता है (मैं नहीं करता) और फिर इसे स्थापित किया जाता है /usr/local/bin/bash, नहीं /bin/bash। एक कड़ाई से POSIX #!/bin/shस्क्रिप्ट अधिक पोर्टेबल होनी चाहिए।

Comments

इस पर ध्यान दें: "जब के रूप में आमंत्रित किया जाता है sh, तो बैश स्टार्टअप फ़ाइलों को पढ़ने के बाद POSIX मोड में प्रवेश करता है।" - gnu.org/software/bash/manual/bashref.html#Bash-POSIX-Mode

— ग्लेन जैकमैन

जब मैं अपनी नौकरी पर आरएचईएल सर्वर के लिए स्क्रिप्ट लिखता हूं, तो मैं #!/bin/bashठीक से उपयोग करता हूं ताकि मैं गैर-पॉसिक्स सुविधाओं का लाभ उठा सकूं।

— मोंटी हार्डर

RHEL पर @MontyHarder IIRC /bin/shयह एक सहानुभूति है bash, क्या यह सही है? मुझे पता है कि CentOS पर यकीन है, हालांकि।

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

@SergiyKolodyazhnyy हाँ, आरएचईएल सर्वर पर मैंने अभी-अभी जाँच की है, यह एक सिमिलिंक है bash। बाइनरी को पता है कि इसे लागू करने के लिए किस नाम का उपयोग किया गया था, और जब इसे बुलाया जाता है तो shयह पुराने स्कूल बॉर्न की तरह काम करता है sh।

— मोंटी हार्डर

Answer 4

तुम ने पूछा था

क्या उबंटू वितरण में लिखी गई शेल स्क्रिप्ट में टिप्पणी #! / बिन / श को रखना सही है?

उत्तर इस बात पर निर्भर करता है कि आप शेल स्क्रिप्ट में क्या लिखते हैं।

• यदि आप पोर्टेबल POSIX- अनुरूप लिपियों का कड़ाई से उपयोग करते हैं, और किसी भी bash- विशिष्ट कमांड का उपयोग नहीं करते हैं, तो आप उपयोग कर सकते हैं/bin/sh ।

• यदि आप जानते हैं कि आप कभी भी मशीन को बैश के साथ स्क्रिप्ट का उपयोग कर रहे हैं, और आप बैश-विशिष्ट सिंटैक्स का उपयोग करना चाहते हैं, तो आपको उपयोग करना चाहिए/bin/bash

• यदि आप सुनिश्चित करना चाहते हैं कि स्क्रिप्ट यूनिक्स मशीनों के वर्गीकरण पर काम करेगी, तो आपको करना चाहिए केवल POSIX- अनुरूप वाक्यविन्यास का उपयोग , और/bin/sh

• आप नियमित रूप से उपयोग करते हैं एक और खोल (जैसे ksh , zsh या tcsh ), और अपनी स्क्रिप्ट में है कि सिंटैक्स का उपयोग करना चाहते हैं, तो आप चाहिए उचित दुभाषिया का उपयोग करें (जैसे /bin/ksh93, /bin/zsh, या /bin/tcsh)

Answer 5

"#!" टिप्पणी हमेशा उपयोग नहीं करता है /bin/bashया /bin/sh। यह सिर्फ जो कुछ भी दुभाषिया होना चाहिए, वह केवल शेल स्क्रिप्टिंग के लिए सूचीबद्ध करता है। उदाहरण के लिए मेरी अजगर लिपियाँ आमतौर पर शुरू होती हैं#!/usr/bin/env python ।

अब बीच का अंतर #!/bin/shऔर #!/bin/bashवह यह है कि /bin/shहमेशा के लिए एक सिमलिंक नहीं है /bin/bash। अक्सर लेकिन हमेशा नहीं। उबंटू यहां एक उल्लेखनीय अपवाद है। मैंने स्क्रिप्ट को CentOS पर ठीक काम करते देखा है, लेकिन उबंटू पर असफल रहा क्योंकि लेखक ने बैश-विशिष्ट वाक्यविन्यास का उपयोग किया था #!/bin/sh।

Answer 6

उन सभी महान जवाबों पर थोड़ा ठंडा पानी डालने के लिए क्षमा करें जो कहते हैं कि सभी/bin/sh में मौजूद है यूनिक्स प्रणालियों - यह मौजूद है, अभी तक के सर्वाधिक इस्तेमाल किया यूनिक्स प्रणाली में छोड़कर: एंड्रॉयड।

एंड्रॉइड में इसका शेल है /system/bin/sh, और आम तौर पर कोई रास्ता नहीं है/bin/sh लिंक , यहां तक ​​कि रूट सिस्टम पर भी (क्योंकि सिस्टम सेलाइन और क्षमताओं के उपयोग से बंद हो जाता है (7) बाउंडिंग सेट)।

उन लोगों के लिए जो कहेंगे कि एंड्रॉइड POSIX-अनुरूप नहीं है: न तो अधिकांश लिनक्स और बीएसडी वितरण हैं। और /bin/shइस पथ का अस्तित्व मानक द्वारा अनिवार्य नहीं है :

अनुप्रयोगों को ध्यान में रखना चाहिए कि PATHशेल के मानक को /bin/shया तो माना नहीं जा सकता है /usr/bin/sh, या PATHरिटर्न द्वारा पूछताछ के द्वारा निर्धारित किया जाना चाहिए getconf PATH, यह सुनिश्चित करते हुए कि लौटाया गया पथनाम एक पूर्ण पथनाम है और शेल निर्मित नहीं है।

Comments

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

— स्टीफन चेज़लस

@ क्रिस्टोफर, कौन सा getconf? उदाहरण के लिए सोलारिस 11.4, क्या यह एक होगा /usr/bin? एक /usr/xpg4/bin(SUSv2 अनुपालन के लिए), एक /usr/xpg6/bin(SUSv3 अनुपालन के लिए)? /usr/xpg7/bin(SUSv4 के लिए)?

— स्टीफन चेज़लस

@ StéphaneChazelas अगर हम इरादे को पहचानने के लिए तैयार हैं, तो मुझे लगता है कि मैं आसानी से कुछ लाइनस टोरवाल्ड्स या थियो डी रैडट को खोद सकता हूं ताकि वे इस बात की परवाह न करें कि वे पोसिक्स ;-) के बारे में ज्यादा परवाह नहीं करते हैं और ज्यादातर एम्बेडेड सिस्टम लिनक्स पर आधारित हैं। + बिजीबॉक्स, जो विशिष्ट यूनिक्स जैसी प्रणाली की तुलना में शायद ही कम पॉसिक्स-अनुरूप है। और a) एंड्रॉइड वास्तव में एक "एम्बेडेड" सिस्टम नहीं है और b) एक एंड्रॉइड सिस्टम को एक खोल के बिना POSIX- अनुरूप बनाया जा सकता है/bin/sh

— मॉसवी

@ मॉसवी, आप जो कहते हैं वह ज्यादातर सच है। लेकिन Torvalds केवल लिनक्स कर्नेल के लिए बोल सकते हैं। चेत रमी बैश के लिए पोसिक्स अनुपालन के बारे में परवाह करता है, रेडहैट पॉसक अनुपालन के बारे में परवाह करता है (वे ऑस्टिन समूह को प्रायोजित करते हैं और अपने समूह की बैठकों में बैठते हैं, वे बहुत सारे जीएनयू सॉफ़्टवेयर को बनाए रखते हैं)। विचार यह है कि POSIX एकमात्र मानक है जो अधिकांश यूनिक्स जैसी प्रणालियों को देखता है। उपयोगकर्ता POSIX अनुपालन के बारे में परवाह करते हैं क्योंकि इससे विभिन्न प्रणालियों के लिए सॉफ्टवेयर पोर्टेबल होना आसान हो जाता है। यह आदर्श नहीं है, लेकिन यह कुछ भी नहीं से बेहतर है। Android की अपनी प्रोग्रामिंग API है, POSIX वास्तव में एक चिंता का विषय नहीं है।

— स्टीफन चेजेलस