هوايتي هي فتح "فلسفة UNIX" الخاصة بـ McIlroy على شاشة واحدة أثناء قراءة mana على شاشة أخرى.

غالبًا ما يتم إعادة صياغة أول مبادئ McIlroy على أنها "افعل شيئًا واحدًا ، ولكن افعل جيدًا". هذا هو اختصار لكلماته ، "إنشاء برامج تؤدي شيئًا واحدًا جيدًا". لعمل جديد ، قم بإنشاء برامج جديدة ، بدلاً من تعقيد البرامج القديمة عن طريق إضافة "وظائف" جديدة.

يعطي McIlroy مثالاً:

يبدو من المستغرب بالنسبة إلى الغرباء أن جامعي UNIX لا يصدرون قوائم: تتم الطباعة بشكل أفضل ويتم تكوينها بمرونة أكبر باستخدام برنامج منفصل.

إذا فتحت المساعدة ls، فستبدأ بعلامة "

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

أي" ، وهي عبارة عن علامات من حرف واحد lsلتضمين جميع الأحرف الصغيرة ، باستثناء {jvyz}14 حرفًا كبيرًا ، @و 1. هذا هو 22 + 14 + 2 = 38 فقط خيارات الحرف الواحد.

في Ubuntu 17 ، lsلن تعرض المساعدة لـ ملخصًا عاديًا ، ولكن سترى أن lsهناك 58 خيارًا (بما في ذلك --helpو --version).

دعونا نرى ما إذا كانت هذه حالة فريدة أو حالة طبيعية. لنقم بعمل قائمة ببعض الأوامر الشائعة ، مرتبة حسب تكرار الاستخدام.

يوضح الجدول عدد خيارات سطر الأوامر لمختلف v7 Unix (1979) ، و slackware 3.1 (1996) ، و ubuntu 12 (2015) ، و ubuntu 17 (2017). كلما زادت المعلمات ، كانت الخلايا أغمق (على مقياس لوغاريتمي).

نرى أنه على مر السنين يزداد عدد الخيارات بشكل كبير: كقاعدة عامة ، تصبح السجلات معتمة من اليسار إلى اليمين (المزيد من الخيارات) ، ولا توجد حالات عندما تصبح السجلات أخف (خيارات أقل). أدان

McIlroy منذ فترة طويلة الزيادة في عدد الخيارات والحجم والوظائف العامة للفرق ¹ :

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

ومن المفارقات أن أحد الأسباب وراء العدد المتزايد لخيارات سطر الأوامر هو قول McIlroy الآخر: "كتابة برامج لمعالجة تدفقات النص لأنها واجهة عالمية" (انظر lsكمثال).

إذا تم إرسال بيانات منظمة أو كائنات ، يمكن ترك التنسيق إلى المرحلة النهائية. ولكن في حالة النص العادي ، يتم الخلط بين التنسيق والمحتوى ؛ نظرًا لأنه لا يمكن إجراء التنسيق إلا من خلال تحليل المحتوى ، فإن الأوامر عادة ما تضيف خيارات التنسيق للراحة. وبالإضافة إلى ذلك، لا يمكن أن يؤديها على شكل عندما يطبق مستخدم علمه بنية البيانات، و "تشفير" معرفة الحجج ل cut، awk،sedوما إلى ذلك (يستخدم المستخدم أيضًا معرفته بكيفية عمل هذه البرامج مع التنسيق ، لأنها مختلفة بالنسبة للبرامج المختلفة ، لذلك يجب أن يعرف المستخدم ، على سبيل المثال ، كيف cut -f4 تختلف عن awk '{ print $4 }² ) هذا أكثر صعوبة من تمرير وسيطة أو اثنتين إلى الأمر التالي في تسلسل ، وهذا ينقل تعقيد الأداة إلى المستخدم.

يقول الناس في بعض الأحيان أنهم لا يريدون دعم البيانات المنظمة ، لأنه بعد ذلك في الأداة العالمية يجب على المرء دعم العديد من التنسيقات. لكن يجب عليهم بالفعل دعم العديد من التنسيقات لإنشاء أداة عالمية. لا يمكن لبعض الأوامر القياسية قراءة الإخراج من أوامر أخرى لأنها تستخدم تنسيقات مختلفة. على سبيل المثال ، wc -wUnicode لا يتعامل معها بشكل صحيح ، وما إلى ذلك. لقول أن "النص" هو تنسيق عالمي هو نفسه القول بأن "ثنائي" هو تنسيق عالمي.

يقال أنه لا يوجد بديل لمثل هذا التعقيد لأدوات سطر الأوامر. لكن الأشخاص الذين يقولون إنهم لم يحاولوا أبدًا استخدام بديل ، مثل PowerShell. لدي الكثير من الشكاوى حول PowerShell ، ولكن نقل البيانات المنظمة والقدرة على العمل بسهولة مع البيانات المنظمة دون الحاجة إلى الاحتفاظ بالبيانات الوصفية في رأسي حتى أتمكن من نقلها إلى أدوات سطر الأوامر الصحيحة في الأماكن المناسبة في خط الأنابيب ليست من شكاوي ³ .

عندما يتم إخبارك أن البرامج يجب أن تكون بسيطة ومتوافقة أثناء معالجة النص ، يتظاهر هؤلاء الأشخاص بأن البيانات النصية لا تحتوي على بنية للتحليل ⁴ . في بعض الحالات ، يمكننا التفكير في كل شيء على أنه صف واحد ، مفصولة بمسافات ، أو كجدول به فواصل صف وأعمدة ( مع سلوك لا يتوافق بالطبع مع الأدوات الأخرى ). هذا يضيف القليل من المتاعب. لا تزال هناك حالات حيث يضيف تسلسل البيانات إلى تنسيق نص عادي تعقيدًا كبيرًا ، لأنه بسبب بنية البيانات ، يتطلب التسلسل البسيط للنص في وقت لاحق جهود تحليل كبيرة لإعادة استيعاب البيانات بطريقة ذات معنى.

سبب آخر يجعل الفرق الآن لديها المزيد من الخيارات هو أن الأشخاص قد أضافوا إشارات ملائمة للوظائف التي يمكن تنفيذها بواسطة خط أنابيب من عدة فرق. هذه الممارسة مستمرة منذ Unix v7 ، حيثlsظهر خيار لتغيير ترتيب الفرز (على الرغم من أنه يمكن القيام بذلك عن طريق تمرير الإخراج إلى tac).

مع مرور الوقت ، لمجرد الراحة ، أضافت معلمات إضافية. على سبيل المثال ، mvيمكن الآن للأمر الذي كان بدون معلمات في الأصل نقل الملف وإنشاء نسخة احتياطية في نفس الوقت (ثلاثة خيارات ؛ طريقتان مختلفتان لتحديد نسخة احتياطية ، أحدهما يأخذ وسيطة والآخر لا يأخذ وسيطات ، يقرأ وسيطة ضمنية من متغير بيئة VERSION_CONTROL؛ خيار آخر يسمح لك بتجاوز لاحقة النسخ الاحتياطي الافتراضية). الآن mvلا تزال هناك خيارات لعدم الكتابة فوق الملفات أو الكتابة فوق الملفات الأحدث فقط.

mkdirبرنامج آخر لم يكن لديه خيارات من قبل. اليوم ، تتم إضافة جميع علاماتها ، باستثناء خيارات الأمان لـ SELinux أو SMACK ، بالإضافة إلى أرقام المساعدة والإصدارات ، للراحة فقط: تعيين أذونات الدليل الجديد وإنشاء أدلة رئيسية إذا لم تكن موجودة.

في tailالبداية كان هناك خيار واحد فقط -number، يشير إلى نقطة البداية للعمل. ثم أضفنا كل من التنسيق والخيارات لتسهيل التنسيق. -zيستبدل العلم فاصل الخط بـ null. فيما يلي أمثلة أخرى للخيارات المضافة للراحة: -fللطباعة عند ظهور تغييرات جديدة ، -sولضبط الفاصل الزمني للمهلة بين التحقق من التغييرات / الرمز> -f ، وأيضًا -retryلإعادة محاولة الوصول إلى الملف إذا لم يكن متاحًا.

ينتقد McIlroy المطورين لإضافة كل هذه الخيارات ، لكنني شخصياً أشعر بتحسن. على الرغم من أنني لم أستخدم بعضًا منها أبدًا ، إلا أنني نادرًا ما استخدمت البعض الآخر ، ولكن هذا هو جمال معلمات سطر الأوامر - على عكس الواجهة الرسومية ، فإن إضافة هذه المعلمات لا تربك الواجهة. نعم ، مانا وتساعد على التورم ، ولكن في عصر Google و Stackoverflow ، على أي حال ، العديد من جوجل فقط أي سؤال ، بدلاً من قراءة مانا.

بالطبع ، تؤدي إضافة الخيارات إلى زيادة الحمل على المشرفين. لكن هذا دفع عادل للفوائد التي يجلبونها. بالنظر إلى نسبة عدد المشرفين والمستخدمين ، فمن المنطقي وضع عبء إضافي على الأول ، وليس على الثاني. هذا مشابه لملاحظة غاري برنهاردت أنه من الحكمة أن تتدرب على الأداء 50 مرة. إذا كان الجمهور 300 شخص ، فإن نسبة الوقت الذي يقضيه في مشاهدة الأداء إلى الوقت الذي يقضيه في التدريبات سيظل 6: 1. بالنسبة لأدوات سطر الأوامر الشائعة ، تكون هذه النسبة أكثر تطرفًا.

قد يجادل البعض في أن كل هذه الخيارات الإضافية تضع عبئًا إضافيًا على المستخدمين. هذا ليس خاطئًا تمامًا ، لكن عبء التعقيد هذا سيكون موجودًا دائمًا. السؤال هو أين بالضبط. إذا كنت تتخيل أن مجموعة من أدوات سطر الأوامر مع غلاف تشكل لغة يمكن للجميع كتابة طريقة جديدة ، وفي حالة الشعبية ، يتم إضافة الطريقة بشكل فعال إلى المكتبة القياسية ، ويتم تحديد المعايير من خلال البديهيات مثل "كتابة برامج لمعالجة تدفقات النص ، لأنها عالمية واجهة "، ثم ستتحول اللغة إلى فوضى غير مترابطة للكتابة فقط ، إذا كنت تأخذها بالكامل. على الأقل ، بفضل الأدوات مع مجموعة واسعة من الخيارات والوظائف ، يمكن لمستخدمي Unix استبدال مجموعة عملاقة من الأدوات غير المتناسقة بشكل كبير بمجموعة كبيرة من الأدوات التي ،على الرغم من أنها غير متناسقة مع بعضها البعض من الخارج ، إلا أنها تتمتع ببعض الاتساق الداخلي.

يشير McIlroy إلى عدم التفكير في صندوق الأدوات. مثل ، يجب على الآباء المؤسسين لـ Unix الجلوس في نفس الغرفة والتفكير بعناية حتى توصلوا إلى مجموعة من الأدوات المتسلسلة "البساطة غير العادية". لكنها لن تتوسع ، فلسفة يونكس نفسها أدت حتمًا إلى الفوضى التي نحن فيها. ليس الأمر أن شخصًا لم يفكر طويلًا أو صعبًا. النقطة هي فلسفة لا تتعدى نطاق فريق صغير نسبيًا بفهم ثقافي مشترك يمكن أن يتسع في غرفة واحدة.

إذا أراد شخص ما كتابة أداة تستند إلى "فلسفة يونكس" ، فسيكون لدى أشخاص مختلفين آراء مختلفة حول معنى "البساطة" أو مبدأ "فعل شيء واحد" ⁵ كيف يجب أن تعمل الأداة بشكل صحيح - وسوف يزدهر التضارب في اللون الخصيب ، ونتيجة لذلك ستحصل على تعقيد هائل ، على غرار اللغات غير المتناسقة بشكل كبير مثل PHP. يسخر الناس من PHP و JavaScript لمختلف الشذوذ والتناقضات ، ولكن مثل اللغة والمكتبة القياسية ، فإن أي غلاف شائع مع مجموعة من أدوات * nix الشائعة ، مجتمعة ، أسوأ بكثير وتحتوي على تعقيد عشوائي أكثر بكثير بسبب التناقضات حتى في نفس توزيع Linux . لا يمكن أن يكون الأمر خلاف ذلك. إذا قارنت توزيعات Linux و BSD و Solaris و AIX وما إلى ذلك ، فإن مقدار التعقيد العشوائي الذي يجب على المستخدمين مراعاته عند تبديل الأنظمة ، يحجب تناقض PHP أو JavaScript.تعد لغات البرمجة الأكثر سخرية على نطاق واسع أمثلة حقيقية على التصميم الرائع مقارنة بها.

من أجل الوضوح ، أنا لا أقول إنني أنا أو أي شخص آخر يمكن أن أتعامل بشكل أفضل مع التطور في السبعينيات ، مع الأخذ في الاعتبار المعرفة المتاحة في ذلك الوقت ، وإنشاء نظام سيكون مفيدًا في ذلك الوقت وأنيقًا اليوم. بالطبع ، من السهل النظر إلى الوراء والعثور على مشاكل في الماضي. أنا ببساطة أختلف مع تعليقات بعض خبراء يونكس ، مثل McIlroy ، الذين يلمحون إلى أننا نسينا أو لم نفهم قيمة البساطة. أو كين طومسون ، الذي يقول أن لغة C هي لغة آمنة مثل أي لغة أخرى ، وإذا كنا لا نريد ظهور أخطاء ، فنحن بحاجة فقط إلى كتابة رمز بدون أخطاء. تشير التعليقات من هذا النوع إلى أن القليل لم يتغير على مر السنين. يزعم ، في السبعينيات قمنا ببناء أنظمة بنفس الطريقة اليوم ، وعلى مدار خمسة عقود من الخبرة الجماعية ، لم تعلمنا عشرات الملايين من الأشخاص سنوات. وإذا لجأنا إلى الأصول ، إلى مبدعي يونكس ، فسيكون كل شيء على ما يرام. مع كل الاحترام الواجب ، لا أوافق.

التطبيق: الذاكرة

على الرغم من أن شكاوى McIlroy حول الانتفاخ للثنائيات خارج نطاق هذه المقالة قليلاً ، إلا أنني سألاحظ أنني اشتريت جهاز Chromebook في عام 2017 مع 16 غيغابايت من ذاكرة الوصول العشوائي مقابل 300 دولار. قد يكون ثنائي 1 ميغا بايت مشكلة خطيرة في عام 1979 ، عندما تم تجهيز Apple II القياسي بـ 4 كيلوبايت من الذاكرة. بلغت تكلفة Apple II 1،298 دولارًا في عام 1979 ، أو 4،612 دولارًا في عام 2020. يمكنك اليوم شراء جهاز Chromebook غير مكلف أقل من 1/15 من هذا السعر ، في حين أنه يحتوي على ذاكرة أكبر بأربعة ملايين مرة. تبدو الشكاوى من أن استخدام الذاكرة قد نما آلاف المرات سخيفة بعض الشيء عندما (محمول!) يكلف الجهاز طلبًا بحجم أرخص ولديه ذاكرة أكبر بأربعة ملايين مرة.

يعجبني التحسين ، لذلك قمت بتضييق صفحتي الرئيسية إلى حزمتين (ستكون هناك واحدة إذا كان CDN يدعم المستوى العالي من brotli) ، ولكن هذا شرط جمالي بحت ، أفعل ذلك من أجل المتعة. اختناق أدوات سطر الأوامر لا يستخدم الذاكرة ، ووقت تحسين ذاكرة أداة بحجم ميغا بايت واحد يشبه تقليل الصفحة الرئيسية إلى حزمة واحدة. ربما هواية ممتعة ، ولكن ليس أكثر.

منهجية تجميع الجدول

يتم الحصول على تكرار استخدام الأوامر من الملفات العامة لتاريخ الأوامر على github ، ولا يتوافق بالضرورة مع تجربتك الشخصية. تم حساب الأوامر "البسيطة" فقط ، باستثناء حالات مثل curl و git و gcc (يحتوي الأخير على أكثر من 1000 خيار) و wget. مفهوم البساطة نسبي. لم يتم أيضًا أخذ أوامر shell المضمنة ، مثل 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 علامة -f كـ rm من أجل منع رسالة حول وجود ملف هدف غير قابل للكتابة.

ولكن -fلا يعتبر علامة في الجدول ، لأن الخيار غير موجود بالفعل.

ينتهي الجدول في عام 2017 لأنه تمت كتابة المسودة الأولى من هذه المقالة. الآن فقط تمكنوا من قراءته.

حول هذا الموضوع

مناقشة Mjd لفلسفة Unix ، مع أفكار حول / usr / bin / time mess مقابل مقابل المدمج في الوقت
نكتة 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. يختلف هذا الاقتباس قليلاً عن الإصدار الشائع لأنني شاهدت الفيديو الأصلي . بقدر ما أستطيع أن أقول ، يتم أخذ جميع نسخ هذا الاقتباس على الإنترنت (فهارس Bing و DuckDuckGo و Google) من نفس النسخ لشخص واحد. هناك بعض الغموض ، لأن الصوت رديء الجودة ، وأسمع كلمات مختلفة قليلاً عما سمعه ذلك الشخص. [لكي ترجع]

2. مثال آخر على كيفية انتقال التعقيد إلى المستخدم ، لأن الفرق المختلفة تتعامل مع التنسيق بشكل مختلف ، هو تنسيق الوقت . وقت الصدفة المدمج time، بالطبع ، غير متوافق مع /usr/bin/time. يجب أن يكون المستخدم على دراية بهذه الحقيقة ومعرفة كيفية التعامل معها. [لكي ترجع]

3. على سبيل المثال ، لأي كائن يمكنك استخدامه ConvertTo-Jsonأو ConvertTo-CSV. أو "cmdlets" لتغيير عرض خصائص الكائن . يمكنك كتابة ملفات تهيئة التنسيق التي تحدد طرق التنسيق المفضلة لديك.

طريقة أخرى للنظر إلى هذا من خلال منظور قانون كونواي . إذا كان لدينا مجموعة من أدوات سطر الأوامر التي أنشأها أشخاص مختلفون ، غالبًا من منظمات مختلفة ، فستكون هذه الأدوات غير متسقة بشكل كبير إذا لم يتمكن شخص ما من تحديد المعيار وإجبار الناس على قبوله. يعمل هذا بشكل جيد نسبيًا على Windows ، وليس فقط PowerShell.

إحدى الشكاوى الشائعة ضد Microsoft هي التغيير الهائل في واجهة برمجة التطبيقات ، غالبًا لأسباب تنظيمية غير فنية (على سبيل المثال ، راجع إجراءات ستيفين سينوفسكي كما هو موضح في الردود على تغريدة عن بُعد ). انها حقيقة. ومع ذلك ، من وجهة نظر مستخدم ساذج ، فإن برامج Windows القياسية ، كقاعدة عامة ، تنقل البيانات غير النصية بشكل أفضل بكثير من * nix. تعود تغطية البيانات غير النصية في Windows إلى COM على الأقل في عام 1999 (وربما OLE و DDE ، تم إصدارهما في 1990 و 1987 ، على التوالي).

على سبيل المثال، إذا قمت بنسخ من فو، التي تدعم تنسيق ثنائي Aو Bفي بار، الذي يدعم تنسيقات Bو Cثم نسخ من شريط لباز، الذي يدعم CوD، كل شيء سيعمل بشكل جيد ، حتى لو لم يكن لدى Foo و Baz تنسيقات مدعومة شائعة.

عندما تقص أو تنسخ شيئًا ما ، "يخبر" التطبيق بشكل أساسي الحافظة التي يمكن أن توفر بها تنسيقات البيانات. عند اللصق في تطبيق ، قد يطلب التطبيق النهائي بيانات بأي من التنسيقات المتاحة. إذا كانت البيانات موجودة بالفعل في الحافظة ، فإن Windows يوفرها. إذا لم يكن الأمر كذلك ، يتلقى Windows البيانات من التطبيق المصدر ، ثم ينقلها إلى التطبيق الهدف ، ويتم تخزين نسخة لبعض الوقت. إذا قمت "بقص" من Excel ، فسوف يقول "أنت" أن لديه بيانات متاحة بالعديد من التنسيقات. مثل هذا النظام جيد جدًا للتوافق ، على الرغم من أنه لا يمكن بالتأكيد تسميته بسيطة أو في أضيق الحدود.

بالإضافة إلى الدعم الجيد للعديد من التنسيقات ، يكفي أن تبدأ العديد من البرامج في التعامل مع هذه الميزات بشكل جيد ؛ في Windows ، خارج الصندوق ، عادة ما يكون هناك دعم جيد للحافظة.

افترض أنك قمت بنسخ ولصق كمية صغيرة من النص. في معظم الحالات ، لن تحدث مفاجآت على نظامي التشغيل Windows أو Linux. ولكن لنفترض الآن أنك نسخت بعض النص ، وأغلقت البرنامج الذي نسخت منه ، ثم لصقته. يميل العديد من المستخدمين إلى التفكير في أنه عند تخزين البيانات في الحافظة ، وليس في البرنامج الذي يتم نسخها منه. في نظام التشغيل Windows ، عادةً ما تتم كتابة البرنامج وفقًا لهذا التوقع (على الرغم من أن مستخدمي واجهة برمجة تطبيقات الحافظة لا يجب أن يفعلوا ذلك تقنيًا). هذا أقل شيوعًا في Linux مع X ، حيث يكون النموذج العقلي الصحيح لمعظم البرامج هو أن النسخ يحفظ مؤشرًا على البيانات التي لا تزال تنتمي إلى البرنامج الذي يتم نسخه منه. بمعنى ، لن يعمل الإدخال إذا تم إغلاق البرنامج.عندما قابلت (بشكل غير رسمي) المبرمجين ، فوجئوا بذلك عادةً ، ما لم يعملوا حقًا مع وظيفة النسخ واللصق لتطبيقهم. عندما قابلت غير المبرمجين ، وجدوا عادة هذا السلوك ليس مفاجئًا فحسب ، بل مربكًا أيضًا.

عيب نقل الحافظة إلى نظام التشغيل هو أن نسخ كميات كبيرة من البيانات أمر مكلف. افترض أنك قمت بنسخ كمية كبيرة من النص ، أو الكثير من الجيجابايت أو نوع من الكائنات المعقدة ، ثم لا تقم بلصقه. في الواقع ، لا تريد نسخ هذه البيانات من برنامجك إلى نظام التشغيل بحيث يتم تخزينها هناك ومتاحة. يقوم Windows بذلك بحكمة: لا يمكن للتطبيقات توفير بيانات إلا عند الطلب ، إذا اعتبرت مفيدة. في حالتنا ، عندما يغلق المستخدم البرنامج ، يمكنه تحديد ما إذا كان سيتم وضع البيانات في الحافظة أو حذفها. في هذه الحالة ، ستعرض العديد من البرامج (على سبيل المثال ، Excel) "حفظ" البيانات في الحافظة أو حذفها ، وهو أمر معقول تمامًا.

يمكن تنفيذ بعض هذه الميزات على Linux. على سبيل المثال،تصف مواصفات ClipboardManager آلية الحفظ ، وعادة ما تدعمها تطبيقات GNOME (وإن كان هناك بعض الأخطاء ) ، لكن الوضع في * nix يختلف حقًا عن الدعم الشامل لتطبيقات Windows ، حيث يتم تنفيذ الحافظة المختصة عادةً. [لكي ترجع]

4. مثال آخر هو أدوات فوق جامعي الحديث. دعنا نعود ونلقي نظرة على مثال Macilroy الكنسي ، حيث يتخصص مترجمو Unix المناسبون إلى حد كبير بحيث يتم الإدراج بواسطة أداة منفصلة. لكن هذا تغير اليوم ، على الرغم من بقاء أداة قائمة منفصلة. لدى بعض جامعي لينكس شعبية حرفيا الآلاف من الخيارات - وهي غنية بالميزات للغاية. على سبيل المثال ، واحدة من العديد من وظائف الحديث clang هي التحليل الثابت. في وقت كتابة هذه السطور ، كان هناك 79 اختبارًا روتينيًا للتحليل الساكن و 44 اختبارًا تجريبيًا.. إذا كانت هذه أوامر منفصلة ، فسيظلون يعتمدون على نفس البنية التحتية الأساسية للمترجم ويفرضون نفس عبء الصيانة - من غير المعقول في الواقع أن تعمل أدوات التحليل الثابتة هذه مع النص العادي وإعادة تعريف سلسلة أداة المترجم بأكملها اللازمة الحصول على نقطة حيث يمكنهم إجراء تحليل ثابت. يمكن أن تكون أوامر منفصلة بدلاً من دمجها في رنة ، لكنها ستظل تعتمد على نفس الآلية وإما تفرض عبء الصيانة والتعقيد على المترجم (الذي يجب أن يدعم واجهات مستقرة للأدوات التي تعمل فوقه) ، أو أنها ستكون ثابتة استراحة.

إن القيام بكل شيء في النص من أجل البساطة يبدو جميلًا ، ولكن في الواقع ، فإن التمثيل النصي للبيانات ليس هو ما تحتاجه غالبًا إذا كنت تريد القيام بعمل مفيد حقًا.

نفس الرنة هي ببساطة أكثر وظيفية من أي مترجم موجود في عام 1979 ، أو حتى جميع المترجمات التي كانت موجودة في عام 1979 مجتمعة ، بغض النظر عما إذا تم تنفيذها بواسطة أمر مترابط أو الآلاف من التعليمات الأصغر. من السهل أن نقول أنه في عام 1979 كان كل شيء أبسط وأننا ، المبرمجين المعاصرين ، ضلوا الطريق. ولكن في الواقع ، من الصعب تقديم تصميم أبسط بكثير وسيقبله الجميع حقًا. من المستحيل أن يحافظ مثل هذا التصميم على جميع الوظائف والتشكيلات الموجودة وأن يكون بسيطًا مثل شيء من عام 1979. [لكي ترجع]

5. منذ نشأتها ، انتقل curl من دعم ثلاثة بروتوكولات إلى 40. هل يعني ذلك أنها "تقوم بأربعين شيئًا" ، وهل تتطلب فلسفة يونكس أن يتم تقسيمها إلى 40 أمرًا منفصلاً؟ يعتمد على من تسأل. إذا كان كل بروتوكول هو فريقه الخاص ، والذي تم إنشاؤه ودعمه من قبل شخص آخر ، فسوف نواجه نفس الفوضى التي تحدث مع الفرق. معلمات سطر أوامر غير متناسقة ، تنسيقات إخراج غير متناسقة ، على الرغم من حقيقة أن كل هذه هي تدفقات نصية ، وما إلى ذلك. هل هذا يقربنا من البساطة التي يدعو إليها McIlroy؟ يعتمد على من تسأل. [لكي ترجع]

تعقيد أوامر وحدة التحكم ، 1979-2020

التطبيق: الذاكرة

منهجية تجميع الجدول

حول هذا الموضوع

More articles: