पोर्टेबल शेल प्रोग्रामिंग के लिए संसाधन


65

पोर्टेबल शेल प्रोग्रामिंग के लिए क्या संसाधन मौजूद हैं? अंतिम उत्तर सभी लक्षित प्लेटफार्मों पर परीक्षण करना है, लेकिन यह शायद ही कभी व्यावहारिक है।

POSIX / एकल यूनिक्स विशिष्टता एक शुरुआत है, लेकिन यह आप न तो बताता है कि प्रत्येक कार्यान्वयन के समर्थन के स्तर है, और न ही क्या आम एक्सटेंशन मौजूद हैं। आप प्रत्येक कार्यान्वयन के प्रलेखन को पढ़ सकते हैं, लेकिन यह बहुत समय लेने वाला है और पूरी तरह से सटीक नहीं है।

मुझे लगता है कि एक आदर्श प्रारूप POSIX कल्पना का कुछ प्रकार का समुदाय-एनोटेट संस्करण होगा, जहां प्रत्येक सुविधा को विभिन्न कार्यान्वयनों के बीच अपने समर्थन स्तर द्वारा एनोटेट किया जाता है। क्या वहां ऐसी कोई चीज है? या अन्य उपयोगी संसाधन हैं?

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


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

1
किसी को ( autoconfऔर Metaconfigपर्ल rn) के लिए संशोधन इतिहास की खान की जरूरत है और एक ही स्थान पर सभी चाल और उनके व्याख्यात्मक टिप्पणियों को इकट्ठा करना होगा।
गीकोसोर

@geekosaur: अच्छा सुझाव। मैंने कभी भी ऑटोकॉन्फ़ के आंतरिक हिस्सों पर ध्यान नहीं दिया है, क्या कोई ऐसा है जो किसी को अपनी स्क्रिप्ट लिखते समय एक गाइड के रूप में उपयोग कर सकता है? यदि हां, तो यह मेरे प्रश्न का एक अच्छा उत्तर होगा, भले ही यह निश्चित नहीं हो।
गाइल्स

5
मुझे यकीन है कि आप दोनों इसे आसानी से पा सकते हैं, लेकिन इस धागे का अनुसरण करने वाले अन्य लोगों के लाभ के लिए, यहां ऑटोकॉन्फ़ मैनुअल से एक प्रासंगिक पृष्ठ का लिंक दिया गया है: gnu.org/software/hello/manual/autoconf/Portable शैल
.

जवाबों:


32

ऑटोकॉनफ मैनुअल में पोर्टेबल शेल प्रोग्रामिंग पर एक सेक्शन है

हालाँकि यह विशेष रूप से POSIX को लक्षित नहीं कर रहा है, लेकिन पोर्टेबल शेल कोड लिखने का प्रयास करते समय यह संभवतः सबसे पूर्ण संग्रह है कि क्या करना है और क्या नहीं।


3
यह सबसे अच्छे संसाधनों में से एक है और एम 4 में कोड लिखते समय बनाया गया था जिसमें शेल कोड का उत्पादन करना था जो कि संभव के रूप में कई गोले भर में पोर्टेबल था।
टिम पोस्ट

6

के अलावा dashऔर posh, वहाँ bournesh(या bsh), विरासत बॉर्न शैल , पता लगाने के लिए इस्तेमाल किया जा सकता है कि Bashisms

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


2
ध्यान दें कि बॉर्न शेल एक पॉसिक्स शेल नहीं है, आपकी स्क्रिप्ट को बॉर्न शेल के लिए पोर्टेबल बनाता है। इसका मतलब है कि मानक स्क्रिप्ट के लिए अपनी स्क्रिप्ट के सिंटैक्स को डाउनग्रेड करना और बोर्न शेल के सिंटैक्स के बीच आम भाजक तक। जब तक आप प्राचीन प्रणालियों (या सोलारिस 10 और उससे पहले) के लिए पोर्टेबल होना चाहते हैं, तब तक राय के लायक नहीं है और आपके पास मानक श का उपयोग करने का विकल्प नहीं है जो / usr / xpg4 / bin में था)।
स्टीफन चेजलस 16

5

इस उत्तर के समान , पॉश में अपनी स्क्रिप्ट निष्पादित करने का प्रयास करें ।

इसके अलावा, POSIXLY_CORRECTपर्यावरण चर को सच करने के लिए मत भूलना , क्योंकि यह कई कार्यक्रमों (न केवल शेल) का कारण बनता है ताकि पोसिक्स मानकों का अधिक सख्ती से पालन किया जा सके।


4

डैश का उपयोग करके अपनी स्क्रिप्ट लिखना एक शुरुआत हो सकती है।


3
डैश के साथ परीक्षण ksh / bash सुविधाओं पर आकस्मिक निर्भरता से बचने के लिए नंगे न्यूनतम है, लेकिन मैं इससे अधिक के बाद हूं: अन्य गोले में कमियों (जैसे zsh के खराब जाल से निपटने) के बारे में जानना, और शेल उपयोगिताओं में सभी से ऊपर (जैसे OpenBSD की findअभी भी) लागू नहीं किया गया -exec +)।
गाइल्स

FWIW, OpenBSD आजकल findकरता -exec utility {} +है।
Kusalananda

2

थोड़ा विस्तार करने के लिए, आप checkbashismsडेबियन / उबंटू के devscriptsपैकेज में कोशिश कर सकते हैं ।

यह सही नहीं है, लेकिन इसका एक मौजूदा शुरुआती बिंदु होने का लाभ है। उदाहरण के लिए, इसके साथ शास्त्रीय खामियों नहीं देखता sed/ findजीएनयू बनाम बीएसडी / अन्य अंतर के विषय में।

डिफ़ॉल्ट रूप से, यह डेबियन + डैश उन्मुख है, -pध्वज आपके मामले में उपयोगी हो सकता है।


2

आज, आप आमतौर पर एक सिस्टम पर एक POSIX शेल पा सकते हैं, और इसलिए आमतौर पर इसका मतलब है कि आप POSIX भाषा में स्क्रिप्ट कर सकते हैं (modulo अनुपालन बग में चल रहा है)।

एकमात्र समस्या यह है कि /bin/shकभी-कभी पोसिक्स शेल नहीं होता है। और आपको उन #!लिपियों में लाइन को हार्ड-कोड करना होगा जो अच्छे निष्पादन के रूप में व्यवहार करने के लिए हैं; आप उपयोगकर्ता को समस्या पर शोध करने के लिए नहीं कह सकते हैं और फिर अपनी स्क्रिप्ट के रूप में इनवाइट कर सकते हैं /path/to/posix/shell myscript

तो, चाल अपनी स्क्रिप्ट में POSIX सुविधाओं का उपयोग करने के लिए है, लेकिन स्क्रिप्ट को POSIX शेल को स्वचालित रूप से ढूंढें। इसे करने का एक तरीका इस प्रकार है:

#!/bin/sh

# At this point, we may be running under some old shell
# we have to tread carefully.

# note how we use test rather than [ ] syntax and avoid
# depending on test with no argument producing a failure;
# i.e. "test $posix_shell".

if ! test x$posix_shell = x ; then
  # the three possible shell paths are just an example;
  # please extend as necessary.

  for shell in /usr/xpg4/bin/sh /bin/bash /usr/bin/bash ; do
    if test -x $shell ; then
       posix_shell=$shell
    fi
  done
  if test x$posix_shell = x ; then
    echo "no POSIX shell found"
    exit 1
    # or we could avoid bailing here and just fall back on /bin/sh:
    # echo "falling back on /bin/sh: cross your fingers that it works"
    # posix_shell=/bin/sh
  fi
  export posix_shell

  # plain "$@" is broken in ancient shells! 
  # I seem to recall ${@+"$@"}: not sure if that's the right trick.

  exec $posix_shell $0 ${@+"$@"}  # can we count on exec in legacy shells? 
fi

# phew, at this point in the script we have been re-executed and are
# being interpreted by some reasonably modern shell. We can use $(...)
# command substitution, and other features.

अन्य दृष्टिकोण हैं, जैसे कोड पीढ़ी। एक छोटे से स्क्रिप्ट के साथ अपनी स्क्रिप्ट को बढ़ावा दें जो बिना # के स्क्रिप्ट फ़ाइलों का एक निकाय लेता है! लाइन, और एक जोड़ता है।

सबसे खराब संभव बात यह है कि आप पूरी स्क्रिप्ट लिखना इस तरह से शुरू करें कि वे 1981 से बॉर्न शेल पर चलें। यह केवल तभी आवश्यक है जब आपको एक ऐसे सिस्टम के लिए लिखना होगा जिसमें वास्तव में कोई अन्य शेल न हो ।

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