एक CLI- उन्मुख प्रोग्रामर का वर्कफ़्लो GUI- उन्मुख एक से कैसे भिन्न होता है?

Question

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

अभी:

• मैं कुछ साइड प्रोजेक्ट्स को C / C ++ / D / C # / Java / Python जैसे विजुअल स्टूडियो, एक्लिप्स आदि भाषाओं में कोड करता हूं, और उन्हें बिल्ड सेटिंग्स सेट करके रन करता हूं, और F5 को बिल्ड / रन करने के लिए दबाता हूं।

• मैं काम पर एक वेब प्रोग्राम विकसित कर रहा हूं, ताकि एक सर्वर सेट करने के लिए Django का उपयोग करना, एक डेटाबेस से कनेक्ट करना, आदि ... लगभग सभी SciTE पाठ संपादक के भीतर।

• नियमित कार्यक्रमों को शुरू करने के लिए, मैं लॉन्ची का उपयोग करता हूं ... अभी भी कोई टर्मिनल नहीं है। :)

• फ़ाइलों और व्हाट्सएप की प्रतिलिपि बनाने के लिए, मैं चित्रमय फ़ाइल प्रबंधक (विंडोज एक्सप्लोरर, नॉटिलस) में एक नियमित रूप से खोज / चाल का उपयोग करता हूं।

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

• काम पर: निर्माण प्रणाली से जुड़ने और एक परियोजना स्थापित करने के लिए, मैं सिर्फ उन उपकरणों का उपयोग करता हूं जिन्हें मेरे उपयोग के लिए ग्रहण में एकीकृत किया गया है - टर्मिनल या किसी भी चीज की आवश्यकता नहीं है (हालांकि मैं निश्चित रूप से एक टर्मिनल का उपयोग करने का स्वागत करता हूं अगर मैं वास्तव में चाहते हैं)

सीएलआई में इन चीजों को करना कैसा है? कौन से भाग अधिक / कम कुशल हो जाते हैं? ज्यादातर सीएलआई में काम करने के लिए एक बदलाव से सबसे बड़ा लाभ प्राप्त करने के लिए मेरे वर्कफ़्लो के किन पहलुओं को बदलना होगा? दूसरे शब्दों में ... यदि आपने जादुई रूप से मुझे एक कमांड-लाइन गुरु में बदल दिया, तो मेरी नई कोडिंग वर्कफ़्लो मेरे वर्तमान, जीयूआई-केंद्रित, चीजों को करने के तरीके से कैसे भिन्न होगी?

Comments

क्या यह आपके पिछले प्रश्न का डुप्लिकेट नहीं है: programmers.stackexchange.com/questions/82519/… ?

— चार्ल्स ई। ग्रांट

@Charles: हाँ की तरह, नहीं की तरह। चैट पर जाएं और मेरे चैट इतिहास पर एक नज़र डालें, यदि आप इसमें रुचि रखते हैं तो यह कहां से आ रहा है।

— user541686

@Charles यह उस प्रश्न का एक नया और बेहतर संस्करण है। पुराने को संपादित करने से उसे मिले उत्तरों को अमान्य कर दिया जाएगा, इसलिए हमने इसके बजाय एक साफ स्लेट से शुरू करना चुना।

— एडम लेअर

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

— स्टीव ३४

en.wikipedia.org/wiki/Common_Language_Infrastructure

— Den

Answer 1

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

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

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

यदि आप डिबग को बार-बार धकेलने में अपना समय व्यतीत करना चाहते हैं, तो एक GUI धीमा हो सकता है, लेकिन जैसे ही उपयोग के मामले अधिक जटिल हो जाते हैं, तो कोई रास्ता नहीं है कि CLI रख सकते हैं।

Comments

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

— विटोर पाय

@Vitor: अगर आपका रुचि रखते हैं, को देखने के msdn.microsoft.com/en-us/devlabs/debuggercanvas डीबगर कैनवास के 5 मिनट के वीडियो के लिए

— Carson63000

+1 वास्तव में, मैं कल्पना नहीं कर सकता कि आप एक टर्मिनल में विजुअल स्टूडियो की सभी विशेषताओं को कैसे प्राप्त करेंगे ...

— user541686

Answer 2

मुझे लगता है कि सबसे बड़ा अंतर व्यक्तिगत कार्यों पर नहीं बल्कि दो चीजों पर पड़ता है:

सबसे पहले और सबसे महत्वपूर्ण, स्वचालन। सीएलआई स्वाभाविक रूप से स्क्रिप्ट योग्य है जो आमतौर पर विंडोज पर कठिन होता है। मैंने सुना है कि चीजें PowerShell के साथ बेहतर हुई हैं लेकिन मैंने इसका उपयोग नहीं किया है।

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

डिबगिंग के लिए gdb अच्छी तरह से काम करता है, लेकिन मैं आमतौर पर VS डिबगर को प्राथमिकता देता हूं। यह शायद Microsoft का अब तक का सबसे बेहतरीन सॉफ्टवेयर है।

निर्माण और चलने वाली चीजों के लिए: बनाते हैं। या बैश। जहां कहीं भी।

विकास के लिए: emacs (हाल ही में vi, ओह शर्म से कन्वर्ट!)। Vi अगर ssh के माध्यम से काम कर रहा है।

मुझे वास्तव में ग्रहण करने की आदत नहीं है। मुझे लगता है कि यह एक "मन की आकृति" समस्या है: यह मेरा फिट नहीं है।

Answer 3

मेरे लिए, दृश्य स्टूडियो से एक CLI वर्कफ़्लो पर स्विच करना बहुत सारे * निक्स कमांड्स को याद करता है। जब भी मैंने SVN चेकइन में गड़बड़ की तो इसमें कुछ सिरदर्द भी शामिल थे।

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

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

एक दूसरे से बेहतर नहीं है, लेकिन पूरी तरह से GUI आधारित वातावरण से टर्मिनल में स्विच करना निश्चित रूप से एक यात्रा थी।

Comments

+1 मुझे "यूनिक्स आदमी" के साथ उस दिलबर्ट की याद दिलाता है: यहाँ एक चौथाई, बच्चा है; अपने आप को एक बेहतर ऑपरेटिंग सिस्टम खरीदने जाओ। :)

— लूसर ड्रोग

Answer 4

यहां एक प्रोग्रामर से अधिक अवलोकन हैं जो दोनों दुनिया में रह चुके हैं। मैं अन्य उत्तरों में पहले से बनाए गए बिंदुओं को नहीं दोहराऊंगा:

सीएलआई-आधारित विकास विभिन्न कार्यक्रमों का उपयोग करता है, जिनमें से प्रत्येक 1 कार्य करता है। GUI- आधारित विकास 1 बड़े कार्यक्रम (IDE) का उपयोग करता है, जो दर्जनों विभिन्न कार्य करता है। इस एक अंतर के कई परिणाम हैं:

क्योंकि एक IDE का इरादा आपका "घर" है जहां आप हर समय काम करते हैं, वे आपके डेटा को रखने के लिए एक मालिकाना (शायद बाइनरी) प्रारूप का उपयोग कर सकते हैं। संगतता एक बड़ी चिंता नहीं है, क्योंकि वे आपसे एक ही परियोजना पर 2 अलग-अलग आईडीई में काम करने की उम्मीद नहीं करते हैं। दूसरी ओर सीएलआई उपकरण, आम तौर पर सिर्फ सादे पाठ फ़ाइलों के साथ काम करते हैं।

सीएलआई-आधारित विकास के साथ, आप वृद्धिशील रूप से टूल को स्विच कर सकते हैं, या नए टूल को अपने वर्कफ़्लो में एकीकृत कर सकते हैं, और अधिक आसानी से। एक IDE चुनना अधिक-या-कुछ नहीं है, और अपनी IDE को स्विच करना अधिक दर्दनाक है।

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

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

दूसरी ओर, एक आईडीई का लाभ यह है कि यह, ठीक है, "एकीकृत" है। तो आप डिबगर ब्रेकपॉइंट सेट करने के लिए अपने संपादक विंडो में क्लिक कर सकते हैं, और इसी तरह।

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

Answer 5

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

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

वैसे भी जो मैं वास्तव में कहने की कोशिश कर रहा हूं वह यह है कि यह जीयूआई बनाम सीएलआई नहीं होना चाहिए, बल्कि सीएलआई क्या बेहतर है और जीयूआई क्या बेहतर है। क्योंकि अंत में अगर आपकी विचार प्रक्रिया की तुलना में आपका IO धीमा है तो समस्या है।

Answer 6

"रातोंरात एक सीएलआई गुरु में परिवर्तित हो गया?" ऐ, वहाँ रगड़ है। अच्छी तरह से डिज़ाइन किए गए GUI CLI से अधिक खोज योग्य हैं, और नौसिखिया के लिए अधिक क्षमा करने योग्य हैं।

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

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

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

वास्तविक समस्या खराब डिज़ाइन किए गए इंटरफेस की है। अच्छी तरह से डिज़ाइन किए गए इंटरफेस बनाना मुश्किल है, इसलिए वे या तो शिविर में बहुत बार नहीं होते हैं। लेकिन चूंकि गैर-औक्स-विजार्ड सीएलआई की तुलना में आज जीयूआई डिजाइन कर रहे हैं, ...।

(मेरे अन्य बड़े पालतू जीव पीट रहे हैं। जब मुझे 200kB प्रोग्राम के समान कार्य को पूरा करने में मदद करने के लिए 19MB प्रोग्राम होता है, तो कुछ गलत है। DOS के लिए XTree Gold ने किसी भी आधुनिक फ़ाइल प्रबंधक की तुलना में मेरी उत्पादकता को बढ़ाया है। विंडोज 2. विंडोज का उपयोग केवल टाइल किया गया है। विंडोज़। टर्बो सी एक भयानक आईडीई थी। क्यों मेरी नुक्कड़ एक मैक क्लासिक की तुलना में धीमी गति से चलने लगती है? अकेले कर्नेल अब पूरे सिस्टम की तुलना में अधिक डिस्क स्थान क्यों लेता है?)

Answer 7

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

टर्मिनल में प्रोग्रामिंग शायद एक ग्राफिकल एडिटर की तुलना में बहुत बेहतर नहीं है, जब तक कि आप एसएसएच का उपयोग न करें।

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

Answer 8

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

मैंने कीबोर्ड कमांड v। माउस पर एक समान बहस की है।

Answer 9

जिस तरह से मैं काम करता हूं वह जीयूआई के लिए बहुत दूर है।

विशिष्ट उपयोग:

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

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