एक-लाइनर बनाम स्क्रिप्ट

Question

मैंने एक-लाइनर्स के बजाय स्क्रिप्ट लिखने के लिए बहुत सारे प्रश्न और उत्तर और टिप्पणियां व्यक्त की हैं (और कभी-कभी डर भी)। तो, मैं जानना चाहूंगा:

• मुझे "वन-लाइनर" के बजाय स्टैंड-अलोन स्क्रिप्ट कब और क्यों लिखनी चाहिए? या ठीक इसके विपरीत?

• दोनों के उपयोग-मामले और पेशेवरों और विपक्ष क्या हैं?

• क्या कुछ भाषाएँ (जैसे कि awk या perl) दूसरों की तुलना में वन-लाइनर्स के लिए बेहतर हैं (जैसे कि अजगर)? यदि हां, तो क्यों?

• क्या यह सिर्फ व्यक्तिगत पसंद की बात है या विशेष परिस्थितियों में एक या दूसरे को लिखने के अच्छे (उद्देश्यपूर्ण) कारण हैं? वे कारण क्या हैं?

परिभाषाएं

• one-liner: कमांड का कोई भी क्रम सीधे शेल कमांड लाइन में टाइप या पेस्ट किया जाता है । अक्सर शामिल पाइपलाइनों और / या इस तरह के रूप भाषाओं के उपयोग sed, awk, perl, और / या उपकरण की तरह grepया cutया sort।

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

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

---

मेरा अपना जवाब है (जो मैं बाद में पोस्ट करूंगा), लेकिन मैं चाहता हूं कि इस विषय पर एक विहित क्यू एंड ए बन जाए, न कि केवल मेरी व्यक्तिगत राय।

Comments

संबंधित: बैश में, कब उर्फ, कब स्क्रिप्ट, और कब एक फ़ंक्शन लिखना है?

— कैस

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

— वेजेंड्रिया

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

— 11:34 पर user3445853

@wjandrea जोड़ने के लिए: regexes। पर्ल के पास उनके लिए एक विशिष्ट वाक्यविन्यास है जिसमें प्रदर्शन करने के लिए ऑपरेशन आदि शामिल हैं। अजगर में आपको एक आयात की आवश्यकता होती है और स्ट्रिंग कॉल के साथ फ़ंक्शन कॉल को तर्क के रूप में लिखा जाता है जो बहुत अधिक वर्ण लेता है। अधिकांश वन-लाइनर्स पाठ में हेरफेर करने के लिए बहुत सारे रेगेक्स का उपयोग करते हैं इसलिए यह एक "बड़ा मुद्दा" है।

— जियाकोमो अल्जेटा

@wjandrea पायथन वन-लाइनर्स के लिए बुरा नहीं है, न कि किसी एक को लिखने में सक्षम होने के अर्थ में नहीं। औसतन मैं 4-5 लाइन स्क्रिप्ट को वन-लाइनर्स में बदलने में सक्षम रहा हूं। लेकिन जैसा कि आपने उल्लेख किया है, यह अन्य भाषाओं की तुलना में अधिक स्पष्ट है (जो कि IMHO यह पायथन के फायदों में से एक है)। इसलिए वे पर्ल या ऑक (जो कि पायथन के विपरीत कुछ पुस्तकालयों के आयात की भी आवश्यकता नहीं है) की तुलना में डबल या ट्रिपल कैरेक्टर काउंट में प्रवेश कर सकते हैं, और यही सबसे अधिक लोगों की शिकायत है - उन वन-लाइनर्स की लंबाई। लेकिन फिर, IMHO यह चरित्र गिनती के बारे में बहस करने के लिए क्षुद्र है; अगर कुछ काम करता है - यह काम करता है

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

Answer 1

व्यावहारिक अनुभव के आधार पर एक और प्रतिक्रिया।

मैं एक-लाइनर का उपयोग करूंगा यदि यह "दूर फेंक" कोड था जिसे मैं तुरंत प्रॉम्प्ट पर लिख सकता था। उदाहरण के लिए, मैं इसका उपयोग कर सकता हूं:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

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

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

सामान्यीकरण, कोई भी कह सकता है

• एक लाइन

  • सरल कोड (यानी सिर्फ "कुछ" बयान), एक विशिष्ट एक-बंद उद्देश्य के लिए लिखा गया है
  • कोड जब भी जरूरत हो जल्दी और आसानी से लिखा जा सकता है
  • डिस्पोजेबल कोड

• लिपि

  • वह कोड जो (शायद) एक या दो बार से अधिक उपयोग किया जाएगा
  • "कुछ" बयानों से अधिक आवश्यक जटिल कोड
  • कोड जिसे दूसरों को बनाए रखना होगा
  • दूसरों द्वारा समझा जाने वाला कोड
  • कोड अप्राप्त चलाने के लिए (उदाहरण के लिए, cron)

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

Comments

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

— एंथनी जी -

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

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

@MontyHarder ऐसे मामलों के लिए मैं उन्हें स्क्रिप्ट के रूप में सहेजता हूं और फिर उन्हें git रेपो में संग्रहीत करता हूं। मैं तो बस उन्हें किसी भी मशीन पर स्थापित कर सकता हूं जो मुझे एक साधारण गिट क्लोन के माध्यम से चाहिए। वह काम के लिए है। व्यक्तिगत उपयोग के लिए मैं कभी भी "रेसिपी" फ़ाइल में कोड नहीं लिखता (मैं उदाहरण के लिए जीथब स्निपेट का उपयोग नहीं करता)। मैं अपनी सभी लिपियों को एक $ HOME / बिन निर्देशिका में सहेजता हूं जो मैंने अपने कॉलेज के दिनों से 1997 में (विश्वविद्यालयों के SunOS पर) रखी है। मुझे उपन्यास न्यूरोमैन्सर से विचार मिला, जहाँ नायक और प्रतिपक्षी दोनों ने हथियार के रूप में उपयोग करने के लिए व्यक्तिगत स्क्रिप्ट / कार्यक्रम रखे

— स्लीबटमैन

हालांकि यह निश्चित रूप से वास्तविक चर्चा के लिए महत्वपूर्ण है, आपके उदाहरण स्क्रिप्ट में आप set -- host1 host2 host3तब for h in "$@"(या बस for h) का उपयोग कर सकते हैं , जो स्क्रिप्ट को पॉस-पोर्टेबल बना देगा। :-)

— wchargin

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

— FreeSoftwareServers 8

Answer 2

एक स्क्रिप्ट लिखें जब:

• अधिक कोड की आवश्यकता है
• आप पठनीयता को महत्व देते हैं
• कोड जोड़ने के लिए, टिप्पणियों को जोड़ना आवश्यक / उपयोगी है
• आपको मापदंडों को पारित करने की आवश्यकता है
• आप स्क्रिप्ट को अपने परिवेश (चर, आदि) में चलाना चाहते हैं
• आप शायद कुछ अधिक जटिल उद्देश्य के लिए कोड का पुन: उपयोग / अनुकूलन करने जा रहे हैं

जब एक-लाइनर लिखें :

• केवल थोड़ी मात्रा में कोड आवश्यक है
• आप वर्तमान शेल में परिभाषित चर का उपयोग करना चाहते हैं
• आपको एक त्वरित और गंदे समाधान की आवश्यकता है

Comments

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

— पीटर कॉर्ड्स

Answer 3

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

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

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

पायथन में, इंडेंटेशन सिंटैक्स का हिस्सा है, इसलिए यदि आप एक-लाइनर लिखते हैं, तो आप वस्तुतः भाषा की विशेषताओं का उपयोग उनकी पूर्ण सीमा तक नहीं कर सकते हैं।

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

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

सबसे अच्छा अक्सर अच्छे का दुश्मन होता है , और यह बात यहाँ बहुत लागू होती है।

और अगर आप पर्ल से परिचित हैं, तो आप पहले से ही TMTOWTDI के बारे में सुन सकते हैं: इसे करने का एक से अधिक तरीका है।

Comments

प्लस "या शेल फ़ंक्शन" का उल्लेख करने के लिए

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

Answer 4

कृपया ध्यान दें कि यह एक व्यक्तिगत राय है; नमक के साथ ले।

1. यदि आदेश में फिट बैठता है, कहते हैं, 80 अक्षर, एक लाइनर का उपयोग करें। लंबी कमांड लाइनों के साथ काम करना मुश्किल है। पुनरावृत्ति की समस्या भी है, # 2 देखें

2. यदि आपको एक से अधिक बार कमांड चलाने की आवश्यकता है, तो स्क्रिप्ट का उपयोग करें। एल्स, एक-लाइनर का उपयोग करें, बशर्ते # 1 शर्त पूरी हो।

3. यह बहुत व्यक्तिपरक है, लेकिन हां, मैं एक लाइनर्स के लिए अपने गो-टू टूल्स के रूप में शेल, पर्ल या जाग को देखता हूं।
4. # 1, # 2, # 3 देखें।

Comments

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

— कैस

Upvoted हालांकि बिंदु 4 व्यर्थ की तरह लगता है। :)

— एंथनी जी -

@ कैस: कंट्रोल-एरो-की (या alt + f / alt + b) के साथ आप एक-लाइनर में बहुत तेजी से घूम सकते हैं । खासकर यदि आपके पास अपनी प्रमुख ऑटो-रिपीट सेटिंग्स हैं जैसे 50 / सेकेंड में शॉर्ट-ईश विलंब के साथ 220ms। आप एक-लाइनर के भीतर कंट्रोल-एस / कंट्रोल-आर का उपयोग भी कर सकते हैं, हालांकि यह आपको अन्य इतिहास में वापस ले जा सकता है। यदि आप नियंत्रण-w, alt + backspace, alt + d, और control-y के साथ अच्छे हैं, तो आप बस कीबोर्ड कर्सर आंदोलन के साथ बहुत कुछ कर सकते हैं।

— पीटर कॉर्ड्स

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

— पीटर कॉर्ड्स

@PeterCordes कर्सर को बहुत तेज़ी से आगे बढ़ाता है, जिसकी तुलना आप vi / vim जैसे सभ्य संपादक में नहीं कर सकते। btw, ^ X ^ ई बैश में $ EDITOR या $ VISUAL को आमंत्रित करता है (और कुछ अन्य गोले। zsh भी, मुझे लगता है। विन्यास योग्य)। यह लाइन-फीड्स और इंडेंटेशन को सम्मिलित करके मेरे द्वारा समझ में आने वाली किसी अपठनीय गंदगी को मोड़ने का एक अच्छा तरीका है - उनके बिना नेस्टेड ब्रेसेस या ब्रैकेट्स में खो जाना आसान है। BTW मेरी टर्मिनल विंडो 250 वर्णों से अधिक चौड़ी है, इसलिए मेरे वन-लाइनर्स रैप किए बिना भी बहुत लंबे समय तक मिल सकते हैं।

— कैस

Answer 5

मैं एक-लाइनर को एक अस्थायी विकास उपकरण के रूप में बार-बार संपादित करने के लिए देखता हूं और उपयोग करता हूं जब तक कि मैं जो चाहता हूं वह नहीं करता, या मैं समझता हूं कि उप-कमांड के कुछ सूक्ष्मता कैसे काम करती है।

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

मैंने अपने शेल इतिहास को 5000 से अधिक लाइनों के साथ सेट किया है, प्रति टर्मिनल एक अलग इतिहास के साथ, और एक रिमोट और इतने पर प्रति लॉगिन। मैं इन इतिहासों में एक-लाइन कमांड को खोजने में सक्षम नहीं होने से नफरत करता हूं, जिसे मैंने कुछ हफ़्ते पहले विकसित किया था और मुझे नहीं लगा कि मुझे फिर से इसकी आवश्यकता होगी, इसलिए मेरी रणनीति।

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

Comments

+1 एक-लाइनर्स ऊपर तीर और संपादित करें, नियंत्रित करने के लिए एक स्क्रिप्ट के लिए कमांड लाइन विकल्प को लागू करने के लिए बनाम महान हैं क्या यह क्या यह पर चल रही है से अलग करता है। उदाहरण के लिए lnबनाम ln -sएक लाइनर में हार्ड बनाम सॉफ्ट लिंक के लिए परिवर्तन जो कुछ फाइलों पर लूप करता है।

— पीटर कॉर्ड्स

Answer 6

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

वर्कफ़्लोज़ (स्क्रिप्ट या समकक्ष के रूप में) को ठीक से दस्तावेज़ करने में विफल होने से किसी प्रोजेक्ट पर नए कर्मचारियों को पेश करना कठिन हो जाता है, और लोगों को प्रोजेक्ट से बाहर स्थानांतरित करना भी कठिन हो जाता है। यह अतिरिक्त रूप से किसी भी प्रकार के ऑडिटिंग को कठिन बनाता है, और बग्स को ट्रैक करना असंभव हो सकता है।

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

अन्य कार्यस्थलों के समान / अलग रीति-रिवाज या अपेक्षाएं हो सकती हैं, शायद नीचे भी लिखी गई हों।

घर पर आप जो मन करे वो करते हैं।

उदाहरण के लिए, मैं जैसे ही खोल में कुछ गैर-तुच्छ करता हूं, मैं स्क्रिप्ट लिखता हूं , जैसे कि U & L प्रश्न का उत्तर सबमिट करने से पहले, या जब भी मुझे इसे चलाने से पहले कमांड के व्यक्तिगत घटकों या कमांड के सेट का परीक्षण करने की आवश्यकता होती है " असली "।

मैं दोहराए जाने वाले कार्यों के लिए स्क्रिप्ट भी लिखता हूं जो मैं वास्तव में हर बार उसी तरह करना चाहता हूं, भले ही वे सरल हों, जैसे

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

मैं के लिए खोल कार्य (बहुत ही कम उपनाम) का उपयोग सुविधा इंटरैक्टिव गोले में, उदाहरण के लिए (डिफ़ॉल्ट रूप से कुछ आदेश के लिए विकल्पों को शामिल करने -Fके लिए ls) या कुछ आदेशों की विशेष बदलाव बनाने के लिए ( pmanयहाँ एक है manआदेश है कि POSIX मैनुअल में केवल दिखता है, उदाहरण के लिए) ।

Answer 7

ऐसा लगता है कि मैं इस पर एक अल्पसंख्यक दृष्टिकोण रखता हूं।

शब्द "स्क्रिप्ट" जानबूझकर भ्रामक है, इससे छुटकारा पाएं। यह सॉफ्टवेयर है जो आप वहां लिख रहे हैं, भले ही आप पूरी तरह से उपयोग कर रहे हों bashऔर awk।

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

यदि आपके पास प्रवेशकों की एक टीम है, तो सबसे सरल vim /root/bin/x.shपरिवर्तन-संबंधित संचार, कोड पठनीयता और क्रॉस-सिस्टम वितरण के संदर्भ में एक आपदा है। अक्सर एक गंभीर खराबी को कथित "भारी" प्रक्रिया की तुलना में अधिक समय / पैसा खर्च होता है।

मैं वास्तव में उस "भारी" प्रक्रिया के लायक किसी भी चीज के लिए वन-लाइनर्स पसंद नहीं करता। उन्हें कुछ कीस्ट्रोक्स के साथ तेजी से पुन: उपयोग किया जा सकता है, यदि आप जानते हैं कि अपने शेल इतिहास का प्रभावी ढंग से उपयोग कैसे करें; आसानी से असंबंधित प्रणालियों (जैसे विभिन्न ग्राहकों) के बीच चिपकाया जाता है।

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

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

Comments

अच्छा बिंदु: मुझे "स्क्रिप्ट" शब्द "प्रोग्राम" खुद पसंद है।

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

Answer 8

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

एक बार, मेरा अपना "उपयोगी" छोटी लिपियों से भरा~/bin था , जिन्हें मैंने लिखा था। लेकिन मुझे एहसास हुआ कि उनमें से ज्यादातर ने उस दिन का उपयोग किया जिस दिन मैंने उन्हें लिखा था, और फिर कभी नहीं। इसलिए जितना अधिक समय बीतता है, मेरी निर्देशिका उतनी ही छोटी होती जाती है।bin

मुझे नहीं लगता कि स्क्रिप्ट लिखने में कुछ भी गलत है । यदि आप कल्पना करते हैं कि आप या कोई और इसे फिर से उपयोग कर सकता है, तो हर तरह से, एक स्क्रिप्ट लिखें। यदि आप "ठीक से इंजीनियर" बनाना चाहते हैं, तो इसके लिए एक सहायक स्क्रिप्ट है, हर तरह से। (यहां तक ​​कि अगर कोई भी कभी भी इसका उपयोग नहीं करता है, तो यह लिखना अच्छा अभ्यास है।)

कारण मैं स्क्रिप्ट को किसी भी अधिक नहीं लिखता (और, मुझे लगता है, "वन-लाइनर्स" के पक्ष में है):

• binनिर्देशिका अव्यवस्था एक लागत है। जब तक वे वास्तव में वहाँ नहीं हैं, मैं चीजों को वहाँ नहीं रखता हूँ।
• मेरे द्वारा उपयोग की जाने वाली स्क्रिप्टिंग भाषाएँ वे भाषाएँ हैं जिनका मैं उपयोग करता हूँ ; मैं अब तक उनके साथ वास्तव में नया हूँ। जब भी मुझे इसकी आवश्यकता होती है, एक-लाइनर को फिर से तैयार करना काम की तरह महसूस नहीं करता है; मैं (री) टाइपिंग के बोझ से राहत पाने के लिए स्क्रिप्ट को रखने और सहेजने और उपयोग करने के लिए एक जनादेश महसूस नहीं करता। (अन्य बातों के अलावा, किसी समय यह याद रखना एक स्क्रिप्ट क्या है याद रखने के बोझ से कम हो जाता है।)
• चीजों को दोबारा बोझ की तरह महसूस करने का एक और कारण है: कमांड इतिहास। बहुत सारे एक-लाइनर हैं जिन्हें मैंने लिपियों के रूप में सुनिश्चित नहीं किया है, भले ही मैं हर दिन उनका उपयोग करता हूं - लेकिन मुझे उन्हें फिर से लिखना नहीं है; मैं उन्हें इतिहास से याद करता हूं। इस तरह वे गरीब-आदमी की पटकथा या उपनाम की तरह हैं।

Answer 9

मेरा मानना ​​है कि अधिकांश समय एक "वन-लाइनर" के लिए अनुरोध वास्तव में "ध्वनि काटने" के लिए एक अनुरोध है, जो है:

पत्रकारिता के संदर्भ में, एक ध्वनि काटने की विशेषता एक छोटे वाक्यांश या वाक्य से होती है जो उस सार को पकड़ लेता है जो वक्ता कहने की कोशिश कर रहा था, और इसका उपयोग जानकारी को संक्षेप में करने के लिए किया जाता है ...

लोग चाहते हैं और सबसे छोटे कोड के लिए अनुरोध करें जो पूछे गए प्रश्न के समाधान को प्रदर्शित करता है।

कभी-कभी, "ध्वनि काटने" के लिए भाषण को कम करने का कोई तरीका नहीं है और साथ ही एक स्क्रिप्ट को "एक-लाइनर" के रूप में कम करना असंभव हो सकता है। ऐसे मामलों में एक ही संभव उत्तर एक स्क्रिप्ट है।

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

तो, एक विचार या अवधारणा को व्यक्त करने के लिए "एक-लाइनर" लिखें।

अपने सामान्य कोड को एक-लाइनर्स के रूप में पूर्ण स्क्रिप्ट के रूप में लिखें।

Answer 10

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

आप कभी-कभी केवल अनुमान लगा सकते हैं कि क्यू एक त्वरित और गंदे कॉपी पेस्ट समाधान द्वारा बेहतर ढंग से परोसा जाता है, या यदि एक "अच्छा" स्क्रिप्ट ठीक वही है जो क्यू को समझने की आवश्यकता है।

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

शेल इतिहास की फाइलें "एक लाइनर" हैं, लेकिन फिर भी वे बच जाती हैं। बैश फ़ंक्शन operate-and-get-next (C-o)आपको अर्ध-स्वचालित रूप से उन्हें दोहराने देता है।

उल्लेखित शब्द समारोह को मैं शायद ही देख पाऊं। यह "स्क्रिप्ट" और "वन लाइनर्स" दोनों को संग्रहीत करने का तरीका है। और कुछ कीस्ट्रोक्स के साथ आप दोनों प्रारूपों के बीच स्विच कर सकते हैं। एक यौगिक कमांड अक्सर दोनों को फिट कर सकता है।

history -r fileकिसी भी फ़ाइल से एक या कई कमांड लाइन (और टिप्पणियाँ) पढ़ने का तरीका है, न कि केवल डिफ़ॉल्ट इतिहास फ़ाइल से। यह सिर्फ कुछ न्यूनतम आयोजन करता है। आपको कमांड लाइन के (कुछ) संस्करण को पुनः प्राप्त करने के लिए एक बड़े इतिहास फ़ाइल आकार और इतिहास खोज पर निर्भर नहीं होना चाहिए।

कार्यों को एक समान तरीके से परिभाषित किया जाना चाहिए। शुरुआत के लिए, thisfunc() {...}अपने घर डायर में एक फ़ाइल "फ़ंक्शन" में डालें , और इसे स्रोत करें। हाँ यह कुछ ओवरहेड है, लेकिन यह सामान्य उपाय है।

यदि आप प्रत्येक कमांड लाइन और प्रत्येक स्क्रिप्ट भिन्नता को एक अलग फ़ाइल में संग्रहीत करते हैं, तो यह फाइलसिस्टम ब्लॉक का एक (सैद्धांतिक, लेकिन उद्देश्यपूर्ण) अपशिष्ट है।

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

---

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

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

---

दस मिनट। बाद में: मैं सिर्फ यह देखना चाहता था कि क्या मैं "दो सेड प्रोग्राम" कह सकता हूँ या यह "दो सेड सब्स्टीट्यूशन / कॉल" है। लेकिन सीताराम का जवाब छूट गया। मेरा जवाब अभी भी समझ में आता है मुझे उम्मीद है।