`Cp` को मौजूदा फ़ाइलों को चुपचाप अधिलेखित करने के लिए क्यों बनाया गया था? [बन्द है]

Question

मैंने cpनिम्नलिखित आदेशों के साथ परीक्षण किया :

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

तब मैं नकल first.htmlकरने के लिए second.html:

$ cp first.html second.html

$ cat second.html
first

फ़ाइल second.htmlको बिना किसी त्रुटि के चुपचाप अधिलेखित कर दिया जाता है। हालाँकि, अगर मैं एक डेस्कटॉप GUI में एक फ़ाइल को उसी नाम से खींच कर छोड़ देता हूँ, तो यह first1.htmlस्वतः ही प्रत्यय हो जाएगा । यह गलती से किसी मौजूदा फ़ाइल को ओवरराइट करने से बचता है।

cpचुपचाप फाइलों को अधिलेखित करने के बजाय इस पैटर्न का पालन क्यों नहीं करते?

Comments

मुझे लगता है कि केवल कोरयूटिल्स डिजाइनर वास्तव में इस सवाल का जवाब दे सकते हैं, लेकिन यह अभी के लिए काम करने का तरीका है। आमतौर पर ऐप का निर्माण उपयोगकर्ता को यह मानकर किया जाता है कि वे वास्तव में क्या कर रहे हैं और अतिरिक्त प्रॉम्प्ट को कम करने के लिए। यदि आप व्यवहार को बदलना चाहते हैं, तो उपनाम 'cp' को 'cp -i' या 'cp -n'।

— केल्विनक्स

@kevlinux कोरुटिल्स देवता सिर्फ पोसिक्स मानक को लागू कर रहे हैं।

— Kusalananda

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

— प्लाज़्मा एचएच

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

— बार्ड कोपरपुड

ऐसा cpकरने के लिए cp -iया किसी अन्य के लिए उपनाम न करें क्योंकि आपको एक सुरक्षा जाल रखने की आदत होगी, जिससे सिस्टम उपलब्ध नहीं होगा (उनमें से अधिकांश) जो बहुत अधिक जोखिम भरा है। अपने आप को नियमित रूप से सिखाने के लिए बेहतर है cp -iकि अगर आप क्या पसंद करते हैं।

— रीड

Answer 1

cpPOSIX में डिफ़ॉल्ट ओवरराइट व्यवहार निर्दिष्ट किया गया है।

3. यदि source_file नियमित फ़ाइल का प्रकार है, तो निम्न कदम उठाए जाएंगे:

   3.A. यदि dest_file मौजूद है और पिछले चरण द्वारा लिखा गया था, तो व्यवहार अनिर्दिष्ट है। अन्यथा, यदि dest_file मौजूद है, तो निम्नलिखित कदम उठाए जाएंगे:

   3. 3. यदि -i विकल्प प्रभाव में है, तो cp उपयोगिता मानक त्रुटि के लिए संकेत लिखेगा और मानक इनपुट से एक पंक्ति पढ़ेगा। यदि प्रतिक्रिया सकारात्मक नहीं है, तो cp source_file के साथ अधिक कुछ नहीं करेगा और किसी भी शेष फाइल पर जाएगा।

   3.a.ii. Dest_file के लिए एक फाइल डिस्क्रिप्टर को POSIX.1-2017 के सिस्टम इंटरफेसेस वॉल्यूम में परिभाषित खुले () फ़ंक्शन के बराबर कार्य करने से प्राप्त किया जाएगा, जिसे dest_file को पथ तर्क के रूप में उपयोग किया जाता है, और बिट-समावेशी या O_WRONLY और O_TRUNC के रूप में लालाग तर्क।

   3.a.iii। यदि फ़ाइल डिस्क्रिप्टर प्राप्त करने का प्रयास विफल हो जाता है और -f विकल्प प्रभावी होता है, तो cp, POSIX.1-2017 के सिस्टम इंटरफेसेस वॉल्यूम में परिभाषित अनलिंक () फ़ंक्शन के समतुल्य क्रिया करके फ़ाइल को निकालने का प्रयास करेगा। पथ तर्क के रूप में। यदि यह प्रयास सफल होता है, तो चरण 3 बी के साथ सीपी जारी रहेगा।

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

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

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

जब POSIX मानक लिखा जा रहा था, तो मिसाल कायम की गई थी, और मानक के लेखकों को पीछे की संगतता को न तोड़ने के गुणों के बारे में अच्छी तरह से पता था ।

इसके अलावा, जैसा कि दूसरों ने वर्णन किया है, कोई भी उपयोगकर्ता अपने लिए उन सुविधाओं को जोड़ सकता है / सक्षम कर सकता है, शेल उपनामों का उपयोग करके या यहां तक ​​कि एक प्रतिस्थापन cpकमांड का निर्माण करके और $PATHमानक सिस्टम कमांड से पहले प्रतिस्थापन खोजने के लिए उन्हें संशोधित कर सकता है, और सुरक्षा नेट प्राप्त कर सकता है यदि इस तरह से चाहा हे।

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

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

यदि आप स्क्रिप्ट्स में भी प्रॉम्प्टिंग लागू करते हैं, तो कमांड क्या करेगा जब एक ऐसे संदर्भ में चलाया जाए, जिसके आसपास कोई उपयोगकर्ता न हो, जैसे पृष्ठभूमि प्रक्रिया या क्रोन जॉब्स? क्या पटकथा लटकेगी, गर्भपात करेगी, या अधिलेखित होगी?

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

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

Comments

"यह इस तरह काम क्यों करता है?" "क्योंकि मानक ऐसा कहता है।" "मानक ऐसा क्यों कहता है?" "क्योंकि यह पहले से ही काम किया यह पसंद आया।"

— बैप्टिस्ट कैंडेलियर

आखिरी पैराग्राफ असली कारण है। पुष्टिकरण संवाद और " क्या आप वास्तव में ऐसा करना चाहते हैं? " संकेत wimps के लिए हैं :-)

— TripeHound

@ बैप्टिस्टकांडेलियर - सहमत। इसकी तरह परम कारण वहाँ से बाहर है, लेकिन इस जवाब की पहुंच से बाहर बस tantalizingly।

— TED

यह आखिरी पैराग्राफ rm -rfइतना प्रभावी क्यों है, भले ही आप वास्तव में इसे अपने घर निर्देशिका में चलाने का मतलब नहीं था ...

— मैक्स वेरनॉन

@TED अजीब बात है कि कैसे कोई भी कभी उल्लेख कैसे अनलिंक (2) syscall भी 'में विफल रहता है' पूछने के लिए "माँ, मैं हो सकता है?" पुष्टि जब भी इन अनंत चर्चाओं फिर पीछे उनके मिठाइयां सिर के लिए। :)

— 22

Answer 2

cpयूनिक्स की शुरुआत से आता है। Posix मानक लिखे जाने से पहले यह अच्छी तरह से था। वास्तव में: Posix ने cpइस संबंध में मौजूदा व्यवहार को औपचारिक रूप दिया ।

हम एपोच (1970-01-01) के आसपास बात कर रहे हैं, जब पुरुष असली पुरुष थे, महिलाएं असली महिला थीं और छोटे जीवों को भड़काती थीं ... (आई डेज्रेस)। उन दिनों, अतिरिक्त कोड जोड़ने से एक कार्यक्रम और बड़ा हो गया। यह तब एक मुद्दा था, क्योंकि यूनिक्स चलाने वाला पहला कंप्यूटर एक पीडीपी -7 (144KB रैम का उन्नयन) था। तो सुरक्षा-सुविधाओं के बिना चीजें छोटी, कुशल थीं।

इसलिए, उन दिनों में, आपको पता होना चाहिए कि आप क्या कर रहे थे, क्योंकि कंप्यूटर में आपके पास बाद में पछतावा करने वाले कुछ भी करने से रोकने की शक्ति नहीं थी।

(ज़ेवर द्वारा एक अच्छा कार्टून है; कंप्यूटर के विकास को खोजने के लिए "ज़ेवर सरवाइक असिस्टेंट पैरिनिअटर" की खोज करें। या http://perinet.blogspirit.com/archive/2012/02/12/zevar-et का प्रयास करें। cointe.html जब तक यह मौजूद है)

वास्तव में रुचि रखने वालों के लिए (मैंने टिप्पणियों में कुछ अटकलें देखीं): cpपहले यूनिक्स पर मूल कोडांतरक कोड (सी बाद में आया) के दो पृष्ठों के बारे में था। प्रासंगिक हिस्सा था:

sys open; name1: 0; 0   " Open the input file
spa
  jmp error         " File open error
lac o17         " Why load 15 (017) into AC?
sys creat; name2: 0     " Create the output file
spa
  jmp error         " File create error

(तो, एक कठिन sys creat)

और, जब हम इस पर हैं: यूनिक्स के संस्करण 2 का उपयोग किया गया (कोड स्निपलेट)

mode = buf[2] & 037;
if((fnew = creat(argv[2],mode)) < 0){
    stat(argv[2], buf);

जो creatपरीक्षण या सुरक्षा उपायों के बिना भी कठिन है । ध्यान दें कि V2 यूनिक्स के लिए सी-कोड cp55 लाइनों से कम है!

Comments

लगभग सही है, यह " छोटे प्यारे " (अल्फा सेंटॉरी से प्राणी) है, " प्यारे छोटे " नहीं!

— ट्रिपहाउंड

@TED: यह पूरी तरह से है के संभावित प्रारंभिक संस्करणों cpबस openके साथ गंतव्य एड O_CREAT | O_TRUNCऔर एक प्रदर्शन read/ writeपाश; यकीन है कि, आधुनिक के साथ cpबहुत सारे knobs हैं कि इसे मूल रूप statसे गंतव्य के लिए पहले से प्रयास करना पड़ता है , और आसानी से पहले अस्तित्व के लिए जांच कर सकता है (और cp -i/ / के साथ करता है cp -n), लेकिन अगर अपेक्षाएं मूल, नंगे हड्डियों के cpउपकरण से स्थापित हुई थीं , तो उस व्यवहार को बदलना मौजूदा स्क्रिप्ट को अनावश्यक रूप से तोड़ देगा। यह आधुनिक गोले की तरह नहीं है, जो सभी के बाद इंटरैक्टिव उपयोग के लिए डिफ़ॉल्ट aliasनहीं बना सकता है cp -i।

— शैडो रेंजर

@ शादो रेंजर - हम्म। आप काफी सही हैं कि मुझे वास्तव में कोई पता नहीं है कि क्या यह करना आसान या कठिन था। टिप्पणी हटा दी गई।

— TED

@ShadowRanger हाँ, लेकिन फिर वह सड़क पर कठिन सबक को तब तक धकेल रहा है जब तक कि यह एक उत्पादन प्रणाली पर नहीं है ...

— chrylis -on हड़ताल-

@ सुरसजेडी: मज़ा! मेरे मूल सिद्धांत को नहीं बदलता है (कि ट्रंकेशन के साथ बिना शर्त खुले होना आसान था, और + के creatबराबर होता है ), लेकिन क्या यह समझाता है कि मौजूदा फाइलों को संभालना इतना आसान क्यों नहीं होगा; ऐसा करने के लिए कोशिश कर रहा स्वाभाविक सुरम्य होगा (आप मूल रूप से करना होगा / अस्तित्व की जाँच करने के लिए, तो का उपयोग , लेकिन बड़े साझा सिस्टम पर, यह हमेशा संभव बार जब आप करने के लिए मिल गया है से है , किसी और फ़ाइल बनाया है और अब आप उड़ा दिया है यह वैसे भी दूर)। मई बिना शर्त के ही अधिलेखित हो सकता है। openO_CREAT | O_TRUNCO_EXCLopenstatcreatcreat

— शैडो रेंजर

Answer 3

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

अभी भी कुछ सुरक्षा उपाय हैं:

• GNU cpएक है -n| --no-clobberविकल्प
• यदि आप एक ही बार में कई फ़ाइलों की प्रतिलिपि बनाते हैं, तो cpशिकायत होगी कि अंतिम एक निर्देशिका नहीं है।

Comments

यह केवल एक विक्रेता विशिष्ट कार्यान्वयन पर लागू होता है और यह सवाल उस विक्रेता विशिष्ट कार्यान्वयन के बारे में नहीं था।

— स्किल

Answer 4

क्या यह "एक समय में एक काम करना" है?

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

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

cpइस तरह से क्यों बनाया गया है?

समस्या यह है कि यूनिक्स 40 साल से अधिक पुराना है।

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

मौजूदा फ़ाइलों को चुपचाप अधिलेखित करने के लिए क्यों डिज़ाइन किया cp गया था ?

संक्षिप्त उत्तर है "मुझे नहीं पता" :-)।

समझ लें कि cpकेवल एक ही समस्या है। मुझे लगता है कि मूल कमांड प्रोग्रामों में से कोई भी फाइल को ओवरराइट करने या हटाने से सुरक्षित नहीं है। आउटपुट पुनर्निर्देशित करने पर शेल में एक समान समस्या होती है:

$ cat first.html > second.html

यह कमांड चुपचाप ओवरराइट भी करती है second.html।

मुझे यह सोचने में दिलचस्पी है कि इन सभी कार्यक्रमों को कैसे नया रूप दिया जा सकता है। इसके लिए कुछ अतिरिक्त जटिलता की आवश्यकता हो सकती है।

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

आप बदल सकते हैं > second.htmlतो यह एक त्रुटि के साथ बंद हो जाता है, अगर second.htmlपहले से मौजूद है। हालांकि, जैसा कि हम उल्लेख किया है, कभी कभी उपयोगकर्ता है किसी मौजूदा फ़ाइल को बदलना चाहते हैं। उदाहरण के लिए, वह एक जटिल कमांड का निर्माण कर सकती है, कई बार कोशिश कर रही है जब तक कि वह वह नहीं चाहती जो वह चाहती है।

rm second.htmlयदि उसे जरूरत है तो उपयोगकर्ता पहले भाग सकता है। यह एक अच्छा समझौता हो सकता है! इसके अपने कुछ संभावित नुकसान हैं।

1. उपयोगकर्ता को फ़ाइल नाम दो बार लिखना होगा।
2. इस्तेमाल करने में भी लोगों को बहुत परेशानी होती है rm। इसलिए मैं और rmभी सुरक्षित बनाना चाहूंगा । पर कैसे? अगर हम बनाने के rmप्रत्येक फ़ाइल नाम दिखाने के लिए और इस बात की पुष्टि करने के लिए कहें, वह अब लिखने के लिए है तीन के बजाय एक के आदेशों की तर्ज। इसके अलावा, अगर उसे अक्सर ऐसा करना पड़ता है, तो वह एक आदत में पड़ जाएगी और बिना सोचे-समझे पुष्टि करने के लिए "y" टाइप कर देगी। तो यह बहुत कष्टप्रद हो सकता है, और यह अभी भी खतरनाक हो सकता है।

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

मुझे लगता है कि मूल यूनिक्स हार्डवेयर - सीमित रैम और डिस्क स्थान, धीमी प्रिंटर पर प्रदर्शित आउटपुट के साथ-साथ सिस्टम और विकास सॉफ़्टवेयर की सीमाओं को समझना भी महत्वपूर्ण है ।

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

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

उपयोग करना > second.htmlथोड़ा सा है जैसे लाइन-एडिटर में कमांड का उपयोग करना। इसका प्रभाव वर्तमान स्थिति पर निर्भर करता है। (यदि second.htmlपहले से मौजूद है, तो इसकी सामग्री को छोड़ दिया जाएगा)। यदि उपयोगकर्ता वर्तमान स्थिति के बारे में निश्चित नहीं है, तो उसे चलने lsया ls second.htmlपहले होने की उम्मीद है ।

एक डिजाइन सिद्धांत के रूप में "सरल कार्यान्वयन"

यूनिक्स डिजाइन की एक लोकप्रिय व्याख्या है, जो शुरू होती है:

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

...

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

https://en.wikipedia.org/wiki/Worse_is_better

Comments

cpएक "समस्या" के साथ लक्ष्य को ओवरराइट क्यों किया जाता है ? यह अंतःक्रियात्मक रूप से अनुमति के लिए पूछना, या असफल होना उतना ही बड़ा "समस्या" हो सकता है।

— Kusalananda

वाह धन्यवाद। दिशानिर्देश के पूरक: 1) ऐसे प्रोग्राम लिखें जो एक काम करते हैं और इसे अच्छी तरह से करते हैं। 2) प्रोग्रामर पर भरोसा करें।

— बीजगणित

@ कुसलानंद डेटा लॉस एक समस्या है। मैं व्यक्तिगत रूप से उस जोखिम को कम करने में दिलचस्पी रखता हूं जो मैं डेटा खो देता हूं। इसके लिए विभिन्न दृष्टिकोण हैं। यह कहना कि यह एक समस्या है इसका मतलब यह नहीं है कि विकल्पों में भी समस्याएं नहीं हैं।

— सोर्सजेडी

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

— sourcejedi

और भी बेहतर cat first.html second.html > first.htmlपरिणाम first.htmlदेगा second.htmlकेवल सामग्री के साथ अधिलेखित होने में । सभी समय के लिए मूल सामग्री खो जाती है।

— doneal24

Answer 5

"Cp" का डिज़ाइन यूनिक्स के मूल डिज़ाइन पर वापस जाता है। वास्तव में यूनिक्स डिजाइन के पीछे एक सुसंगत दर्शन था, जो थोड़ा कम था कि आधे-मजाक को वर्से-इस-बेटर ^{* के} रूप में संदर्भित किया गया था ।

मूल विचार यह है कि कोड को सरल रखना वास्तव में एक अधिक महत्वपूर्ण डिज़ाइन विचार है जो एक संपूर्ण इंटरफ़ेस या "द राइट थिंग" कर रहा है।

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

• सुधार - डिजाइन सभी अवलोकन पहलुओं में सही होना चाहिए। सही से सरल होना थोड़ा बेहतर है।

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

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

^{( जोर मेरा )}

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

जैसा कि उस डिजाइन दृष्टिकोण के साथ एक ओएस क्यों हुआ जो उस समय में निर्मित अन्य सभी ओएस पर जीत गया, निबंध के लेखक के लिए भी एक सिद्धांत था।

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

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

^{* - या क्या लेखक, लेकिन कोई और नहीं, जिसे "द न्यू जर्सी दृष्टिकोण" कहा जाता है} ।

Comments

यह सही जवाब है।

— 21

+1, लेकिन मुझे लगता है कि इसका एक ठोस उदाहरण होना चाहिए। जब आप एक प्रोग्राम का नया संस्करण स्थापित करते हैं जिसे आपने संपादित किया है और फिर से संकलित किया है (और शायद परीक्षण किए गए :-), तो आप जानबूझकर कार्यक्रम के पुराने संस्करण को अधिलेखित करना चाहते हैं। (और आप शायद अपने कंपाइलर से ऐसा ही व्यवहार चाहते हैं। इसलिए शुरुआती UNIX में केवल creat()vs ही है open()। open()अगर यह मौजूद नहीं था तो कोई फ़ाइल नहीं बना सकता। इसे पढ़ने / लिखने / दोनों के लिए केवल 0/1/2 लगते हैं। यह अभी तक नहीं लेता है O_CREAT। और कोई नह O_EXCL) ं है ।

— sourcejedi

@sourcejedi - क्षमा करें, लेकिन खुद एक सॉफ्टवेयर डेवलपर के रूप में, मैं ईमानदारी से दूसरे परिदृश्य के बारे में नहीं सोच सकता हूं, जहां मैं एक कॉपी कर रहा हूं। :-)

— टेड

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

— sourcejedi

Answer 6

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

ध्यान दें कि यह /bin/cpवांछित होने पर चारों ओर एक सुरक्षित आवरण लिखने के लिए पहले दिन से था । * निक्स दर्शन उपयोगकर्ताओं के लिए सरल बिल्डिंग ब्लॉक प्रदान करना है: इनमें से, /bin/cpएक है।