मेरा शौक है एक दूसरे पर मैना को पढ़ते हुए एक मॉनिटर पर McIlroy का "UNIX दर्शन" खोलना ।

McIlroy के सिद्धांतों के पहले को अक्सर "एक काम करो, लेकिन अच्छा करो" के रूप में दोहराया गया है। यह उनके शब्दों के लिए एक संक्षिप्त नाम है, "ऐसे कार्यक्रम बनाएं जो एक काम अच्छी तरह से करते हैं।" नए कार्य के लिए, नए "फ़ंक्शंस" जोड़कर पुराने को जटिल बनाने के बजाय नए प्रोग्राम बनाएं।

McIlroy एक उदाहरण देता है:

यह बाहरी लोगों के लिए आश्चर्यजनक लगता है कि UNIX कंपाइलर लिस्टिंग जारी नहीं करता है: मुद्रण बेहतर तरीके से किया जाता है और एक अलग कार्यक्रम का उपयोग करके अधिक लचीले ढंग से कॉन्फ़िगर किया जाता है।

यदि आप मदद के लिए खोलते हैं ls, तो यह

ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]

उसी के साथ शुरू होता है, एक-अक्षर के झंडे lsमें {jvyz}14 बड़े अक्षरों को छोड़कर, सभी निचले अक्षरों को शामिल किया गया है , @और 1। यह 22 + 14 + 2 = 38 केवल एकल-वर्ण विकल्प हैं।

उबंटू 17 में, मदद के लिए lsएक सामान्य सारांश नहीं दिखाया जाएगा, लेकिन आप देखेंगे कि ls58 विकल्प (सहित --helpऔर --version) हैं।

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

तालिका विभिन्न v7 यूनिक्स (1979), स्लैकवेयर 3.1 (1996), ubuntu 12 (2015), और ubuntu 17 (2017) कमांड के लिए कमांड लाइन विकल्पों की संख्या दिखाती है। अधिक पैरामीटर, कोशिकाओं को गहरा (एक लघुगणकीय पैमाने पर)।

हम देखते हैं कि वर्षों में विकल्पों की संख्या में नाटकीय रूप से वृद्धि होती है: एक नियम के रूप में, बाएं से दाएं (अधिक विकल्प) में रिकॉर्ड गहरा होता है, और ऐसे मामले नहीं होते हैं जब रिकॉर्ड हल्का हो जाता है (कम विकल्प)।

मेक्लोरी लंबे निंदा की है विकल्प, आकार और टीमों के समग्र कार्यक्षमता की संख्या में वृद्धि ¹ :

, , Linux … []. , , . , , … Unix : « ? ?» , - , . , , , . … , .

विडंबना यह है कि कमांड-लाइन विकल्पों की बढ़ती संख्या के कारणों में से एक McIlroy का अन्य कहना है: "पाठ धाराओं के प्रसंस्करण के लिए प्रोग्राम लिखें क्योंकि यह एक सार्वभौमिक इंटरफ़ेस है" ( lsउदाहरण के रूप में देखें )।

यदि संरचित डेटा या वस्तुओं को प्रेषित किया गया था, तो स्वरूपण को अंतिम चरण पर छोड़ा जा सकता है। लेकिन सादे पाठ के मामले में, स्वरूपण और सामग्री मिश्रित होती है; चूंकि स्वरूपण केवल सामग्री पार्स करके किया जा सकता है, कमांड आमतौर पर सुविधा के लिए स्वरूपण विकल्प जोड़ते हैं। इसके अलावा, प्रारूप किया जा सकता है जब कोई उपयोगकर्ता डेटा संरचना के अपने ज्ञान लागू होता है, और "encodes" के लिए बहस का ज्ञान cut, awk,sedआदि (उपयोगकर्ता भी अपने ज्ञान का उपयोग करता है कि ये प्रोग्राम प्रारूपण के साथ कैसे काम करते हैं, क्योंकि यह विभिन्न कार्यक्रमों के लिए अलग है, इसलिए उपयोगकर्ता को पता होना चाहिए, उदाहरण के लिए, यह ² से कैसे cut -f4 भिन्न होता हैawk '{ print $4 }) यह एक क्रम में एक या दो तर्कों को अगले कमांड में पास करने की तुलना में बहुत अधिक परेशानी है, और यह उपयोगकर्ता को टूल की जटिलता को स्थानांतरित करता है।

कभी-कभी लोग कहते हैं कि वे संरचित डेटा का समर्थन नहीं करना चाहते हैं, क्योंकि तब एक सार्वभौमिक टूल में किसी को कई स्वरूपों का समर्थन करना होगा। लेकिन उन्हें पहले से ही एक सार्वभौमिक उपकरण बनाने के लिए कई प्रारूपों का समर्थन करना होगा। कुछ मानक कमांड अन्य कमांड से आउटपुट नहीं पढ़ सकते हैं क्योंकि वे विभिन्न प्रारूपों का उपयोग करते हैं। उदाहरण के लिए, wc -wयूनिकोड इसे सही ढंग से संभाल नहीं पाता है, आदि यह कहना कि "पाठ" एक सार्वभौमिक प्रारूप है, यह कहना कि "बाइनरी" एक सार्वभौमिक प्रारूप है।

यह कहा जाता है कि कमांड लाइन टूल की ऐसी जटिलता के लिए कोई विकल्प नहीं है। लेकिन जो लोग कहते हैं कि उन्होंने कभी विकल्प की कोशिश नहीं की है, पावरशेल जैसा कुछ। मुझे PowerShell के बारे में कई शिकायतें हैं, लेकिन संरचित डेटा का हस्तांतरण और आसानी से संरचित डेटा के साथ काम करने की क्षमता मेरे सिर में मेटाडेटा रखने के लिए है ताकि मैं इसे पाइपलाइन पर सही स्थानों में सही कमांड-लाइन टूल में स्थानांतरित कर सकूं, मेरी शिकायतों में से एक ^{3 नहीं है}।

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

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

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

mkdirएक और कार्यक्रम जिसमें पहले कोई विकल्प नहीं था। आज, इसके सभी झंडे, SELinux या SMACK के लिए सुरक्षा विकल्पों के अपवाद के साथ-साथ सहायता और संस्करण संख्याओं को केवल सुविधा के लिए जोड़ा जाता है: नई निर्देशिका के लिए अनुमतियाँ सेट करना और उनके मौजूद न होने पर मूल निर्देशिका बनाना।

पर tailशुरुआत वहाँ केवल एक ही विकल्प था -numberकाम के लिए प्रारंभिक बिंदु का संकेत,। फिर हमने स्वरूपण की सुविधा के लिए प्रारूपण और विकल्प दोनों को जोड़ा। ध्वज -zरेखा विभाजक को प्रतिस्थापित करता है null। सुविधा के लिए जोड़े गए विकल्पों के अन्य उदाहरण यहां दिए गए हैं: -fनए परिवर्तन दिखाई देने पर प्रिंट करने के लिए, -sपरिवर्तनों / कोड> -f की जाँच के बीच के समय अंतराल को निर्धारित करने के लिए, और यह -retryउपलब्ध न होने पर फ़ाइल तक पहुँचने के लिए पुनः प्रयास करें।

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

बेशक, विकल्प जोड़ने से रखरखाव पर भार बढ़ जाता है। लेकिन यह उन लाभों के लिए एक उचित भुगतान है जो वे लाते हैं। अनुरक्षकों और उपयोगकर्ताओं की संख्या के अनुपात को देखते हुए, पूर्व पर एक अतिरिक्त बोझ डालना तर्कसंगत है, न कि उत्तरार्द्ध पर। यह गैरी बर्नहार्ड की टिप्पणी के समान है कि किसी प्रदर्शन को 50 बार फिर से करना बुद्धिमानी है। यदि दर्शक 300 लोग हैं, तो रिहर्सल पर खर्च किए गए प्रदर्शन को देखने के लिए समय का अनुपात अभी भी 6: 1 होगा। लोकप्रिय कमांड लाइन टूल के लिए, यह अनुपात और भी अधिक चरम है।

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

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

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

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

अनुप्रयोग: मेमोरी

जबकि McIlroy की ब्लोटिंग बायनेरी के बारे में शिकायतें इस लेख के दायरे से थोड़ी बाहर हैं, मैं ध्यान देता हूं कि 2017 में मैंने $ 300 के लिए 16 जीबी रैम के साथ क्रोमबुक खरीदा था। 1 मेगाबाइट बाइनरी 1979 में एक गंभीर समस्या हो सकती है, जब मानक Apple II 4 किलोबाइट मेमोरी से सुसज्जित था। 1979 में Apple II की कीमत $ 1,298 या 2020 में $ 4,612 थी। आज आप एक सस्ती Chrome बुक खरीद सकते हैं, जिसकी कीमत इस कीमत से 1/15 से कम है, जबकि इसमें चार मिलियन गुना अधिक मेमोरी है। शिकायतें हैं कि मेमोरी का उपयोग हजार गुना बढ़ गया है, जब (पोर्टेबल!) मशीन थोड़ी हास्यास्पद लगती है और मशीन की मेमोरी चार मिलियन गुना अधिक होती है।

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

टेबल संकलन पद्धति

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

झंडे दोहराना एक अलग विकल्प नहीं माना जाता था। उदाहरण के लिए, यू git blame -C, git blame -C -Cऔर git blame -C -C -Cअलग व्यवहार, लेकिन वे सभी, एक तर्क के रूप में विचार किया जाएगा, हालांकि -C -Cवे -C वास्तव में विभिन्न तर्क हैं।

तालिका में उप-विकल्पों को एक विकल्प के रूप में गिना जाता है। उदाहरण के लिए, यह lsनिम्नलिखित का समर्थन करता है:

--format=WORD across -x, commas -m, horizontal -x, long -l, single-column -1, verbose -l, vertical -C

सात विकल्पों के बावजूद format, यह एक विकल्प के रूप में गिना जाता है।

स्पष्ट रूप से बेकार के रूप में इंगित किए जाने वाले विकल्पों को अभी भी विकल्प माना जाता है, उदाहरण के लिए ls -g, जिसे नजरअंदाज कर दिया गया है।

एक ही विकल्प के कई संस्करणों को एक विकल्प माना जाता है। उदाहरण के लिए, -Aऔर के --almost-allलिए ls।

यदि प्रमाण पत्र कहता है कि विकल्प मौजूद है, लेकिन वास्तव में इसका अस्तित्व नहीं है, तो इसे ध्यान में नहीं रखा जाता है। उदाहरण के लिए, v7 mv के लिए मदद कहती है:

बैग्स

यदि file1 और file2 अलग-अलग फाइल सिस्टम में हैं, तो mv फाइल को कॉपी करके मूल को डिलीट कर देना चाहिए। इस स्थिति में, स्वामी का नाम प्रतिलिपि प्रक्रिया का नाम बन जाता है, और अन्य फ़ाइलों के साथ कोई भी कनेक्शन खो जाता है।

mv को किसी लक्ष्य फ़ाइल के अस्तित्व के बारे में संदेश को दबाने के लिए rf के रूप में -f ध्वज को स्वीकार करना चाहिए जो कि लेखन योग्य नहीं है।

लेकिन -fइसे तालिका में ध्वज नहीं माना जाता है, क्योंकि विकल्प वास्तव में मौजूद नहीं है।

तालिका 2017 में समाप्त होती है क्योंकि इस लेख का पहला मसौदा तब लिखा गया था। केवल अब उन्हें यह पढ़ने को मिला।

इस विषय पर

एमजीडी की चर्चा यूनिक्स दर्शन की, जिसमें / usr / बिन / समय गड़बड़ बनाम अंतर्निहित समय के विचारों के साथ
Mjd ने 1991 में कमांड विकल्प वितरित करने के बारे में मज़ाक किया
HN के साथ:
p1mrx:

यह विचित्र है कि ls 58 विकल्पों में विकसित हो गया है, लेकिन फिर भी फ़ाइल नाम को \ _ के साथ समाप्त नहीं कर सकता है। 0.

एक अभ्यास के रूप में, निर्देशिका को आकार या तिथि के अनुसार क्रमबद्ध करने का प्रयास करें और सभी मान्य फ़ाइल नामों का समर्थन करते हुए परिणाम xargs में स्थानांतरित करें। अंत में, मैंने बस नाम दिया और स्क्रिप्ट में नाम में \ n के साथ किसी भी फाइल को अनदेखा कर दिया।

whelming_wave:

, (whitespace-in-filenames-safe). printf (od -> sed) , , , , , , . , sort --zero-terminated — GNU , macOS, , .
```
      printf '%b' $(
        find . -maxdepth 1 -exec sh -c '
          printf '\''%s %s\0'\'' "$(stat -f '\''%m'\'' "$1")" "$1"
        ' sh {} \; | \
        sort --zero-terminated | \
        od -v -b | \
        sed 's/^[^ ]*//
      s/ *$//
      s/  */ \\/g
      s/\\000/\\012/g')
```
zsh, , 'command', printf, zsh, escape- . , .

POSIX, , sort.
Unix
?

_{, , -, //.}

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

2. एक और उदाहरण है कि उपयोगकर्ता को जटिलता कैसे दी जाती है, क्योंकि अलग-अलग टीमें अलग-अलग प्रारूपण को संभालती हैं, समय प्रारूपण है । अंतर्निहित शेल समय time, निश्चित रूप से, असंगत है /usr/bin/time। उपयोगकर्ता को इस तथ्य के बारे में पता होना चाहिए और यह पता होना चाहिए कि इसे कैसे संभालना है। [लौटने के लिये]

3. उदाहरण के लिए, किसी भी वस्तु के लिए आप उपयोग कर सकते हैं ConvertTo-Jsonया ConvertTo-CSV। या ऑब्जेक्ट गुणों के प्रदर्शन को बदलने के लिए "cmdlets" । आप स्वरूपण कॉन्फ़िगरेशन फ़ाइलों को लिख सकते हैं जो आपके पसंदीदा स्वरूपण विधियों को परिभाषित करती हैं।

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

Microsoft के खिलाफ एक आम शिकायत एपीआई का बड़े पैमाने पर कारोबार है, जो अक्सर गैर-तकनीकी संगठनात्मक कारणों से होता है (उदाहरण के लिए, स्टीफन सिनोफस्की के कार्यों को एक दूरस्थ ट्वीट के जवाब में वर्णित के रूप में देखें )। यह सच है। हालांकि, एक भोले उपयोगकर्ता के दृष्टिकोण से, मानक विंडोज सॉफ्टवेयर, एक नियम के रूप में, गैर-पाठीय डेटा को * निक्स से बहुत बेहतर प्रसारित करता है। Windows में गैर-पाठीय डेटा का कवरेज 1999 में कम से कम COM (और संभवतः OLE और DDE, क्रमशः 1990 और 1987 में जारी) में वापस आता है।

उदाहरण के लिए, यदि आप फू, जो द्विपदीय प्रारूप का समर्थन करता है से कॉपी Aऔर Bबार है, जो स्वरूपों का समर्थन करता में Bऔर Cउसके बाद बाज को बार है, जो समर्थन से कॉपी CऔरDसब कुछ ठीक काम करेगा, भले ही फू और बाज सामान्य समर्थित प्रारूप न हों।

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

कई प्रारूपों के अच्छे समर्थन के अलावा, यह काफी लंबा है कि कई प्रोग्राम इन सुविधाओं के साथ अच्छी तरह से व्यवहार करना शुरू करते हैं, विंडोज में, बॉक्स के बाहर आमतौर पर अच्छा क्लिपबोर्ड समर्थन होता है।

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

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

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

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

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

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

5. अपनी स्थापना के बाद से, कर्ल तीन प्रोटोकॉल का समर्थन करने से 40 तक चला गया है। क्या इसका मतलब यह है कि यह "40 चीजें करता है", और क्या यूनिक्स दर्शन को इसे 40 अलग-अलग आज्ञाओं में विभाजित करने की आवश्यकता है? निर्भर करता है कि किससे पूछा जाए। यदि प्रत्येक प्रोटोकॉल की अपनी टीम थी, जो किसी अन्य व्यक्ति द्वारा बनाई और समर्थित थी, तो हम टीमों के साथ एक ही गड़बड़ करेंगे। असंगत कमांड लाइन पैरामीटर, असंगत आउटपुट स्वरूप, इस तथ्य के बावजूद कि ये सभी पाठ धाराएं हैं, आदि क्या यह हमें उस सादगी के करीब लाता है जो मैकलॉयर वकालत करता है? निर्भर करता है कि किससे पूछा जाए। [लौटने के लिये]

कंसोल कमांड्स की तारीफ, 1979−2020

अनुप्रयोग: मेमोरी

टेबल संकलन पद्धति

इस विषय पर

More articles: