कमांड लाइन तर्क को डिजाइन करने के लिए अच्छी आदतें क्या हैं?

Question

एप्लिकेशन को विकसित करते समय मैंने आश्चर्यचकित करना शुरू कर दिया - मुझे कमांड लाइन तर्क कैसे डिज़ाइन करना चाहिए?

बहुत सारे प्रोग्राम इस तरह के फॉर्मूले का उपयोग कर रहे हैं -argument valueया /argument value। समाधान जो मेरे मन को आया था argument:value। मैंने सोचा कि यह अच्छा है क्योंकि सफेद जगहों के साथ कोई ऐसा रास्ता नहीं है जिससे मूल्यों और तर्कों को गड़बड़ किया जा सके। इसके अलावा बाएं :चरित्र से पहली बार एक स्ट्रिंग को दो में विभाजित करना आसान है ।

मेरे प्रश्न हैं:

1. क्या लोकप्रिय -argument valueफॉर्मूला argument:value(अधिक पठनीय, लिखने में आसान, बगफ्री, विशेषज्ञ डेवलपर्स द्वारा समझने में आसान) से बेहतर है?
2. क्या कुछ सामान्य रूप से ज्ञात नियम हैं जो मुझे कमांड लाइन तर्क को डिजाइन करते समय पालन करना चाहिए (अगर यह काम करता है तो इसके अलावा) ठीक है?

---

कुछ और विवरणों के लिए कहा मैं इसे प्रदान करूंगा। हालाँकि मुझे लगता है कि उन्हें उत्तरों को प्रभावित नहीं करना चाहिए। सवाल सामान्य तौर पर एक अच्छी आदत के बारे में है। मुझे लगता है कि वे सभी प्रकार के अनुप्रयोगों के लिए समान हैं।

हम एक ऐसे अनुप्रयोग पर काम कर रहे हैं जिसका उपयोग सार्वजनिक स्थानों (स्पर्श कुल, तालिकाओं) में किया जाएगा। अनुप्रयोग Qt क्विक 5 (C ++, QML, JS) का उपयोग करके लिखे गए हैं। डिवाइस में विंडोज 8.1 / 10 स्थापित होगा। हम उपकरणों का प्रबंधन करने के लिए फ्रंट-एंड इंटरफेस प्रदान करेंगे। हालाँकि कुछ उन्नत व्यवस्थापक अपने दम पर एप्लिकेशन को कॉन्फ़िगर करना चाह सकते हैं। यह व्यवसाय की ओर से बहुत महत्वपूर्ण नहीं है, लेकिन जैसा कि मैं काइलिन फोथ ने कहा है कि मैं अपने आवेदन को एक उपयोगकर्ता के लिए दर्द नहीं होना चाहता हूं, से सहमत हूं । इंटरनेट में नहीं मिल रहा है कि मैं क्या चाहता हूँ मैं यहाँ पूछा।

---

अधिक उन्नत स्टैक एक्सचेंज उपयोगकर्ताओं के लिए: मैं चाहता था कि यह प्रश्न सामान्य हो। हो सकता है कि यह समुदाय विकी के लिए योग्य हो (मुझे नहीं पता कि मौजूदा प्रश्न को उत्तरों के साथ परिवर्तित किया जा सकता है)। जैसा कि मैं चाहता हूं कि यह सवाल ऑपरेटिंग सिस्टम और प्रोग्रामिंग लैंग्वेज से स्वतंत्र हो, तो यहां दिखाई देने वाले उत्तर अन्य डेवलपर्स के लिए एक मूल्यवान सबक हो सकते हैं।

Comments

लोकप्रिय कमांड लाइन टूल देखें। उदाहरण के लिए, एकल हाइफ़न अक्सर संयोजन विकल्पों की अनुमति देने के लिए उपयोग किया जाता है। उदाहरण के लिए आप ls -ltrविकल्पों को संयोजित करने के लिए लिख सकते हैं -l, -tऔर -r। GNU शैली कार्यक्रम भी आम तौर पर एक डबल हाइफ़न जैसे शब्द आधारित विकल्पों की अनुमति देते --reverseहैं -r। अन्य लोकप्रिय सम्मेलनों में -hमदद दिखाना, --विकल्पों की समाप्ति का संकेत देना, -स्टड से पढ़ने की अनुमति देने के लिए फ़ाइल नाम के रूप में निर्दिष्ट करना आदि शामिल हैं

— ब्रैंडिन

न तो -argument valueनहीं -argument:valueआम हैं। आम हैं -a value, -avalueऔर, और --argument=value।

— रीइनियरियरपोस्ट

एक लोकप्रिय कमांड लाइन पार्सिंग लाइब्रेरी (आमतौर पर ऐसा कुछ कहा जाता है getopt(s)) का उपयोग करें जहां आप कर सकते हैं।

— रीयरियरपोस्ट

@ k3b हम Qt के साथ काम कर रहे हैं। जैसा कि केविन क्लाइन ने अपनी टिप्पणी में कहा था कि हम पहले से उपलब्ध पुस्तकालय का उपयोग कर सकते हैं। मुझे लगता है कि यह बहु-मंच और अच्छी तरह से सोचा गया है। QCommandLineParser

— फिलिप हजूबस्की

आपके अंतिम ब्लर्ब के साथ समस्या यह है कि तर्क पार्सिंग एक प्लेटफ़ॉर्म-स्वतंत्र मुद्दा नहीं है।

— १६

Answer 1

POSIX सिस्टम (उदाहरण के लिए Linux, MacOSX) पर, कम से कम संभवतः एक शेल टर्मिनल (जैसे अधिकांश) में शुरू किए गए कार्यक्रमों के लिए, मैं GNU कोडिंग सम्मेलनों (जो सामान्य तर्क नामों को भी सूचीबद्ध करता है) और PIXIX उपयोगिताओं के दिशा-निर्देशों पर गौर करने की सलाह दूंगा। , मालिकाना सॉफ्टवेयर के लिए भी:

• हमेशा संभालो --versionऔर--help (यहां तक ​​कि /bin/trueउन्हें स्वीकार करता है !!)। मैं अपशब्द सॉफ्टवेयर के लेखकों समझ नहीं --helpहै, मैं उन्हें नफरत है (क्योंकि prog --help है पहले आदेश मैं एक नए कार्यक्रम पर कोशिश कर रहा हूँ)! अक्सर --helpसंक्षिप्त रूप में देखा जा सकता है-h

• लो --helpसंदेश सूची सभी विकल्प (जब तक आप उनमें से भी कई है ... उस मामले सूची में सबसे आम लोगों और स्पष्ट रूप से कुछ का उल्लेख manपेज या कुछ यूआरएल) और विकल्प के मूलभूत मूल्यों, और शायद महत्वपूर्ण (और इस कार्यक्रम के विशिष्ट ) पर्यावरण चर। विकल्प तर्क त्रुटि पर इन विकल्प सूचियों को दिखाएं।

• स्वीकार -aकम तर्क (एकल पत्र) और कुछ बराबर है --long-argument, इसलिए -a2 --long-argument=2, --long-argument 2; बेशक आप कुछ --only-long-argumentनाम के लिए (शायद ही कभी इस्तेमाल किए गए विकल्पों के लिए) हो सकते हैं ; अतिरिक्त विकल्पों के बिना मॉडल संबंधी तर्कों के लिए -cfआम तौर पर नियंत्रित किया जाता है -c -f, आदि। इसलिए आपका -argument:valueप्रस्ताव अजीब है, और मैं ऐसा करने की सलाह नहीं देता।

• glibc का उपयोग getopt_long या बेहतर (जैसे argp_parse , OCaml में यह Argमॉड्यूल , ...)

• अक्सर उपयोग -मानक इनपुट या आउटपुट के लिए (यदि आप ऐसा नहीं कर सकते, संभाल /dev/stdinऔर /dev/stdoutउन्हें नहीं होने भी कुछ ऑपरेटिंग सिस्टम पर)

• उनके अधिकांश विकल्प सम्मेलनों का पुन: उपयोग करके समान कार्यक्रमों के व्यवहार की नकल करें; विशेष रूप -nसे ड्राई रन (अ ला make) -hके लिए, मदद के लिए, -vवर्बोसिटी, आदि के लिए ...

• --विकल्प और फ़ाइल या अन्य तर्कों के बीच विभाजक के रूप में उपयोग करें

• यदि आपका प्रोग्राम स्टडिन की isattyतुलना में परीक्षण करने के लिए उपयोग करता है, तो एक टर्मिनल है (और उस मामले में "अंतःक्रियात्मक रूप से व्यवहार करें"), गैर-संवादात्मक मोड को बाध्य करने का विकल्प प्रदान करें, इसी तरह यदि आपके प्रोग्राम में GUI इंटरफ़ेस है (और X11 डेस्कटॉप पर परीक्षण ) लेकिन यह भी कर सकता है बैच या कमांड लाइन में उपयोग किया जाता है।getenv("DISPLAY")

• कुछ कार्यक्रम (जैसे gcc) अप्रत्यक्ष तर्क सूचियों को स्वीकार करते हैं, तो @somefile.txtइसका अर्थ है कि कार्यक्रम तर्क पढ़ें somefile.txt; यह तब उपयोगी हो सकता है जब आपका प्रोग्राम बहुत बड़े तर्क (आपके कर्नेल से अधिक ARG_MAX) को स्वीकार कर सकता है

BTW, आप अपने कार्यक्रम और सामान्य गोले (जैसे bashया zsh) के लिए कुछ ऑटो-पूर्ण सुविधाएं भी जोड़ सकते हैं

कुछ पुराने यूनिक्स कमांड (जैसे dd, या यहां तक ​​कि sed) में ऐतिहासिक संगतता के लिए अजीब कमांड तर्क हैं। मैं उनकी बुरी आदतों का पालन नहीं करने की सलाह दूंगा (जब तक कि आप उनमें से कुछ बेहतर संस्करण नहीं बना रहे हैं)।

यदि आपका सॉफ़्टवेयर संबंधित कमांड-लाइन कार्यक्रमों की एक श्रृंखला है, तो गिट से प्रेरणा लें (जो आप निश्चित रूप से एक विकास उपकरण के रूप में उपयोग करते हैं), जो स्वीकार करता है git helpऔर जिसमें git --helpकई हैं gitsubcommandऔरgitsubcommand--help

दुर्लभ मामलों में आप भी उपयोग कर सकते हैं argv[0](अपने कार्यक्रम पर सिमलिंक का उपयोग करके), उदाहरण के लिए bashलागू के रूप में rbashएक अलग व्यवहार (है प्रतिबंधित शेल)। लेकिन मैं आमतौर पर ऐसा करने की सलाह नहीं देता; यह मतलब हो सकता है आपके प्रोग्राम का उपयोग एक स्क्रिप्ट दुभाषिए के रूप में इस्तेमाल किया जा सकता है, तो मामला यानी #!पहली पंक्ति से व्याख्या पर execve (2) । यदि आप इस तरह की तरकीबें करते हैं, तो उन्हें --helpसंदेश सहित, दस्तावेज करना सुनिश्चित करें ।

याद रखें कि POSIX पर शेल में ग्लोबिंग तर्क हैं ( आपके प्रोग्राम को चलाने से पहले !), इसलिए विकल्पों में पात्रों (जैसे *या $या ~) की आवश्यकता से बचें, जिन्हें शेल-एस्केप करने की आवश्यकता होगी।

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

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

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

---

^{ध्यान दें कि /optionएक विंडोज या वीएमएस चीज है। यह POSIX सिस्टम पर पागल होगा (क्योंकि फ़ाइल पदानुक्रम /निर्देशिका सेपरेटर के रूप में उपयोग करता है , और क्योंकि शेल ग्लॉबिंग करता है)। मेरा सारा जवाब ज्यादातर लिनक्स (और POSIX) के लिए है।}

---

पुनश्च यदि संभव हो तो, अपने प्रोग्राम को एक मुफ्त सॉफ्टवेयर बनाएं , आपको कुछ उपयोगकर्ताओं और डेवलपर्स से सुधार मिलेगा (और एक नया प्रोग्राम विकल्प जोड़ना अक्सर एक मौजूदा मुफ्त सॉफ़्टवेयर में जोड़ना सबसे आसान चीजों में से एक है)। इसके अलावा, आपका सवाल अभीष्ट श्रोताओं पर बहुत अधिक निर्भर करता है : किशोरों के लिए एक गेम या दादी के लिए एक ब्राउज़र को कंपाइलर की तुलना में एक ही तरह के विकल्प या राशि की आवश्यकता नहीं होती है, या डेटासेंटर सिस्मैमिन के लिए एक नेटवर्क इंस्पेक्टर, या माइक्रोप्रोसेसर के लिए एक सीएडी सॉफ्टवेयर आर्किटेक्ट या पुल डिजाइनरों के लिए। प्रोग्रामिंग और स्क्रिप्टिंग से परिचित एक इंजीनियर शायद आपकी दादी की तुलना में बहुत अधिक ट्यून करने योग्य विकल्प पसंद करता है, और शायद आप X11 (शायद एक crontabनौकरी में) के बिना अपने एप्लिकेशन को चलाने में सक्षम होना चाहते हैं ।

Comments

सहमत थे, लेकिन git एक बेहतर उदाहरण है। मैं 2016 में भी देखने की सलाह नहीं दूंगा cvs।

— बेसिल स्टारीनेविच

+ अमान्य विकल्प के मामले में बस मदद दिखाएं। उदाहरण के लिए बेकार त्रुटि संदेश प्राप्त करना कष्टप्रद है dd -h।

— डोमिन

GNU प्रोग्राम --helpएक नियम के रूप में समर्थन करता है, लेकिन अक्सर पहचान नहीं करता है कि -hकौन परेशान है। मैं आमतौर पर टाइप करता हूं-जब मैं किसी प्रोग्राम का विकल्प भूल जाता हूं, तो लंबे विकल्प के साथ कमांड को फिर से टाइप करना कष्टप्रद होता है --help। आखिरकार, मैंने टाइप किया -ह क्योंकि मैं कुछ भूल गया था। उपयोगकर्ता को यह याद रखने की अपेक्षा क्यों की जानी चाहिए कि कौन से प्रोगाम को '--help' की आवश्यकता है और किन कार्यक्रमों के लिए हेल्प स्क्रीन दिखाने के लिए '-h' की आवश्यकता है? बस -h और --help दोनों के लिए एक विकल्प शामिल करें।

— ब्रैंडिन

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

— ब्रैंडिन

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

— सोब्रीक

Answer 2

तथ्य यह है कि एक डेटा प्रारूप सम्मेलन लोकप्रिय है इसका लाभ है।

आप आसानी से देख सकते हैं कि एक विभाजक के रूप में = या: या '' का उपयोग करना एक मामूली अंतर है जिसे कम प्रयास के साथ कंप्यूटर द्वारा एक दूसरे में परिवर्तित किया जा सकता है। एक इंसान के लिए यह याद रखने का एक बड़ा प्रयास क्या होगा "अब देखिए, क्या इस तरह से इस्तेमाल किया जाने वाला प्रोग्राम परिसीमन के साथ :या साथ में था =? हम्म्म ..."

दूसरे शब्दों में, भगवान के प्यार के लिए, एक सम्मोहक कारण के बिना अत्यंत सघन सम्मेलनों से विचलित न हों। लोग आपके कार्यक्रम को "मेरे कॉलेज निबंध को सहेजने वाले" के बजाय "अजीब और कष्टप्रद cmdline वाक्यविन्यास के साथ" के रूप में याद करेंगे।

Comments

लगभग सभी भाषाओं के लिए कमांड लाइन तर्क को संभालने के लिए पुस्तकालय के कार्य हैं। उनमें से एक का उपयोग करें।

— केविन क्लाइन

अच्छी सलाह है, लेकिन उन सम्मेलनों क्या हैं? -1

— रबरडैक

आमतौर पर उपयोग किए जाने वाले यूनिक्स उपकरण का एक दिलचस्प उदाहरण है जो जानबूझकर इस सम्मेलन का उल्लंघन ddकरता है : एक key=valueवाक्यविन्यास का उपयोग करता है । इस डिजाइन निर्णय का कारण यह है कि यह उपकरण (उपनाम: d ata d estroyer) गलत तरीके से उपयोग किए जाने पर बहुत अधिक नुकसान पहुंचा सकता है। उपयोगकर्ता को अपनी सामान्य आदत को छोड़ने के लिए मजबूर करके वे उपयोगकर्ता को यह सोचने के लिए मजबूर करते हैं कि वे क्या कर रहे हैं।

— फिलिप

क्या आप निश्चित हैं कि इसका कारण क्या है dd? मेरा मानना ​​है कि यह बस एक बार (1970 के दशक में) कोडित किया गया था जब कर्नेल का ARG_MAX छोटा था, शेल में कोई ऑटो-कंप्लीशन --long-argumentsनहीं था , और मौजूद नहीं था। तब से बेहतर ddपिछड़े संगत बना रहा

— बेसिल स्टायरनेविच

ddएक अन्य OS (UNIX से) से उत्पन्न - IBM के OS / 360 पर एक स्क्रिप्टिंग-भाषा (JCL) - जहां कन्वेंशन अलग थे, UNIX में अधिक या कम अपरिवर्तित होने से पहले - आंशिक रूप से क्योंकि इसका उपयोग करने की संभावना वाले लोग इसे जानते थे। पिछला सिस्टम।

— कोपरपुड

Answer 3

आम आदमी की शर्तों में

जब रोम में हो तो वैसा ही करो जैसा की रोमन करते हैं।

• यदि आपका सीएलआई ऐप लिनक्स / यूनिक्स के लिए है -p valueया --parameter valueकन्वेंशन का उपयोग करता है । लिनक्स में इस तरह के मापदंडों और झंडे को आसान तरीके से पार्स करने के लिए उपकरण हैं।

मैं आमतौर पर ऐसा कुछ करता हूं:

while [[ $# > 0 ]]
do
key="$1"
case $key in
    --dummy)
    #this is a flag do something here
    ;;
    --audit_sessiones)
    #this is a flag do something here
    ;;
    --destination_path)
    # this is a key-value parameter
    # the value is always in $2 , 
    # you must shift to skip over for the next iteration
    path=$2
    shift
    ;;
    *)
    # unknown option
    ;;
esac
shift
done

• यदि आपका सीएलआई ऐप विंडोज के लिए है, तो उपयोग करें /flagऔर /flag:valueकन्वेंशन करें।

• ओरेकल जैसे कुछ ऐप हालांकि न तो उपयोग करते हैं। Oracle उपयोगिताओं का उपयोग करें PARAMETER=VALUE।

• कमांड लाइन में मापदंडों को स्वीकार करने के अलावा, एक चीज जो मुझे पसंद है, वह है पैराफाइल का उपयोग करने का विकल्प प्रदान करना , जो लंबी पैरामीटर चेन से बचने के लिए एक महत्वपूर्ण-मूल्य जोड़ी फाइल है। उसके लिए आपको एक अतिरिक्त --parfile mifile.parपैरामीटर प्रदान करना चाहिए । जाहिर है अगर --parfileउपयोग किया जाता है, तो पैराफाइल के अंदर क्या है, इसके पक्ष में अन्य सभी मापदंडों को छोड़ दिया जाता है।

• एक अतिरिक्त सुझाव कुछ कस्टम पर्यावरण चर का उपयोग करने की अनुमति देता है , उदाहरण के लिए, पर्यावरण चर MYAPP_WRKSPACE=/tmpसेट करना हमेशा सेट करने के लिए अनावश्यक होगा --wrkspace /tmp।

• लिनक्स में पैरामीटर को ऑटो-पूर्णता जोड़ना नहीं भूलते हैं , जिसका अर्थ है कि उपयोगकर्ता आधा स्विच, हिट TABऔर फिर शेल टाइप कर सकते हैं।

Comments

खैर, कई जीएनयू उपयोगिताओं (जैसे gcc) @mifile.parआपके --parfile mifile.parसुझावों की तरह संभालती हैं ।

— बेसिल स्टारीनेविच

यदि आप एक पैरामीटर फ़ाइल है, तो क्या आप अन्य सभी विकल्पों को अनदेखा करने के बारे में सुनिश्चित हैं? यह मुझे सबसे अच्छा लगता है।

— जोनाथन लेफ्लर

मैं पैरामीटर फाइलों के बारे में जोनाथन से सहमत हूं। यदि पैरामीटर फ़ाइल मौजूद है, तो मैं इसे डिफ़ॉल्ट मानों के लिए उपयोग करने की अपेक्षा करता हूं, कमांड लाइन पर दिए गए तर्कों के साथ उन लोगों के लिए लागू किया जाता है जो पैराफाइल में ओवरटॉप होते हैं। यदि किसी कारण से एक पैराफाइल का उपयोग अतिरिक्त कमांड लाइन तर्कों के उपयोग को रोकता है, तो अतिरिक्त तर्कों की उपस्थिति में त्रुटि होनी चाहिए।

— एल्ड्रिच चीज़

@EldritchCheese सीएलआई ऐप्स में मैंने लिखा है, जब एक पैराफाइल दिया जाता है, कोई भी एडिशनल पैरामीटर त्रुटि उत्पन्न करता है।

— ट्यूलेंस कोर्डोवा

यदि एक सक्षम शेल का उपयोग किया जाता है, तो इस तरह के "कॉन्फ़िगरेशन फ़ाइल पैरामीटर" विकल्प आवश्यक नहीं है। जैसे आप अभी लिखते हैं fooCmd -opt1 -opt2 $(cat more_options.opts)। इसलिए मुझे उम्मीद है कि यदि "मूलभूत फ़ाइल पैरामीटर" विकल्प उपलब्ध हो, तो मूल रूप से उसी तरह काम करना चाहिए।

— ब्रैंडिन

Answer 4

एक बात जो अभी तक सामने नहीं आई:

अपने सॉफ़्टवेयर को कमांड लाइन के तर्कों से ऊपर की ओर डिज़ाइन करने का प्रयास करें । अर्थ:

कार्यक्षमता डिज़ाइन करने से पहले, उपयोगकर्ता इंटरफ़ेस डिज़ाइन करें।

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

इसके अलावा, docopt ( http://docopt.org/ ) देखें।

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

Comments

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

— बिल्ली

मैंने docopt की कोशिश की, और मुझे यह पसंद नहीं है। बहुत क्लीनर कोड में परिणाम पर क्लिक करें , हालांकि जब आपके पास सबकुंड होते हैं तो विकल्पों के साथ थोड़ी जीत होती है।

— jpmc26

यह एक विज्ञापन की तरह बहुत ज्यादा है। प्रासंगिक होने पर ही संसाधन का उल्लेख करें .. लेकिन अब जैसा भी है, आपके उत्तर का 50% सिर्फ बाहरी संसाधन को बढ़ावा देने जैसा लगता है।

— ब्रैंडिन

मैं इसे 'डिजाइन मॉडल पहले डिजाइन' के रूप में देखूंगा। उपयोगकर्ता के अनुभव को कार्यक्षमता से अलग करना कई मामलों में एक कृत्रिम अंतर हो सकता है (टूल सीमाएं इंटरफ़ेस को प्रभावित करती हैं)।

— ताम्र .16

Docopt के लिए +1। इसने मेरे सभी सीएलआई दुविधाओं को हल किया, पूरी तरह से दर्द मुक्त। कभी-कभी विज्ञापन को वास्तविक उत्साह से बताना कठिन होता है, लेकिन यहाँ यह है - मैं वर्षों से डॉकटॉप उत्साही रहा हूँ, किसी भी तरह से संबद्ध नहीं;)

— frnhr

Answer 5

कुछ मूल्यवान टिप्पणियाँ पहले से ही (@ फ़्लोरियन, बेसिल) प्रदान की गई हैं, लेकिन मुझे जोड़ने दें ... ओपी कहते हैं,

हम उपकरणों का प्रबंधन करने के लिए फ्रंट-एंड इंटरफेस प्रदान करेंगे। हालाँकि कुछ उन्नत व्यवस्थापक अपने दम पर एप्लिकेशन को कॉन्फ़िगर करना चाह सकते हैं

लेकिन यह भी टिप्पणी:

मैं नहीं चाहता था कि यह प्रश्न मंच या भाषा विशेष का हो

आपको अपने लक्षित दर्शकों - उन्नत प्रशासकों पर विचार करना चाहिए । वे सामान्य रूप से किस प्लेटफॉर्म पर काम करते हैं - विन / यूनिक्स / मैक? और आप किस प्लेटफॉर्म पर ऐप चलाते हैं? उस प्लेटफ़ॉर्म के लिए पहले से ही जो भी CLI कन्वेंशन स्थापित किए गए हैं, उनका पालन करें। क्या आपके "उन्नत" व्यवस्थापक चाहते हैं / GUI आधारित उपकरण की आवश्यकता है?

आप चाहते हैं कि इंटरफ़ेस आंतरिक रूप से और अन्य व्यवस्थापक उपकरणों के अनुरूप हो। मैं बंद करो और लगता है कि नहीं करना चाहती यह है cmd -p <arg>या cmd -p:<arg>या cmd /p <arg>। क्या मुझे उद्धरण चिह्नों की आवश्यकता है कि क्या कोई स्थान है? क्या मैं cmd -p <val1> <val2>या cmd -p <val1> -p <val2>कई लक्ष्यों के लिए? क्या वे विशिष्ट आदेश हैं? Overloadable? cmd -p2 <arg> -p1 <arg>काम भी करता है? है ls -l -r -t dir1 dir2== ls -trl dir1 dir2?

मेरे यूनिक्स व्यवस्थापक टूल के लिए, मैंने हमेशा हीइनर शेल्डोरादो द्वारा दिए गए मार्गदर्शन को ध्यान में रखा है और अन्य संदर्भों का उल्लेख किया है।

सीएलआई को डिजाइन करना जितना महत्वपूर्ण है, यह सुनिश्चित करना है कि आपका एप्लिकेशन GUI से कमांड लाइन के तर्कों के साथ काम करने के लिए डिज़ाइन किया गया है - यानी: GUI और CLI दोनों से बुलाए गए सामान्य कमांड का उपयोग GUI या कोई भी व्यावसायिक तर्क नहीं करता है।

अधिकांश UNIX आधारित प्रशासनिक उपकरण वास्तव में पहले कमांड लाइन टूल्स के रूप में डिज़ाइन किए गए हैं और बशर्ते GUI केवल कमांड लाइन के लिए विकल्पों को "पॉपुलेटिंग" करने की सुविधा प्रदान करता है। यह दृष्टिकोण ऑटोमेशन, रिस्पांस फाइल्स आदि के उपयोग और हैंड्स-ऑफ मैनेजमेंट (मेरे लिए कम काम!) की अनुमति देता है।

जैसा कि क्लासिक टूलसेट w / यह दृष्टिकोण Tcl / Tk है । आपको उपकरण स्विच करने का सुझाव नहीं दे रहा है; पहले एक कमांड लाइन टूल के रूप में ऐप पर एक जीयूआई-आधारित प्रशासनिक ऐप लिखने से डिज़ाइन दृष्टिकोण पर विचार करें; फिर सुविधा के लिए शीर्ष पर GUI परत करें। कुछ बिंदु पर आपको पता चलता है कि GUI एक दर्द (और त्रुटि प्रवण) है, यदि आपको कई कॉन्फ़िगरेशन करने पड़ते हैं और आम तौर पर एक ही विकल्प पर बार-बार प्रवेश करना पड़ता है और आप एक स्वचालित दृष्टिकोण की तलाश करेंगे।

याद रखें कि आपके व्यवस्थापक को सही बक्से में सही मानों को वैसे भी टाइप करना है, इसलिए आप वैसे भी w / GUI से कितना प्रयास कर रहे हैं?

Comments

महान, हाँ! एक सवाल यह भी है: मैं चला सकते हैं ./this-script --hosts <hosts.txt

— फ्लोरियन हीगल