سؤال متى يتم استخدام Bash ومتى تستخدم Perl / Python / Ruby؟


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

كيف يمكنك تحديد موعد استخدام Perl / Python / Ruby على Bash للنص البرمجي؟ لا أعتقد أن أحد البرامج النصية الأولية مع روبي منطقي ، ولكن ماذا عن برنامج نصي أطول قليلاً يضيف حسابات البريد الإلكتروني؟


69
2018-04-21 02:37


الأصل


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


الأجوبة:


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

Bash هي لغة برمجة نصية عامة مثل Python و Ruby و Perl ، لكن لكل منها نقاط قوة مختلفة. بيرل تتفوق في تحليل النص ، تدّعي بايثون أنها الأكثر أناقة بين الباقة ، مخطوطات باش ممتازة في "الأشياء الممتدة حولها" ، إذا كنت تعرف ما أعنيه ، و روبي ... حسناً ، روبي خاص قليلاً في الكثير من الطرق.

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

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

أيضا ، ضع في اعتبارك أن تعلم شل البرمجة هو بسيط جدا. تكمن القوة الحقيقية لها في برامج أخرى ، مثل awk ، sed ، tr ، et al.


41
2018-04-21 03:33



لقد حصلت على بعض الخبرة في كتابة bash ، كما هو الحال مع Ruby ، ​​لكنني أحيانًا لا أعلم ما الذي يجب استخدامه. الاختيار على أساس تفضيل شخصي في تلك اللحظة يبدو سخيفا. لكن أنت محق ، سأسأل نفسي ما أريد أن أفعله واختر أفضل أداة لهذا المنصب. - futlib
أنا شخصياً ، سأستخدم مقياساً للغات التي أعرفها جيداً ، بترتيب تصاعدي من التعقيد والقوة ، واستخدام أبسط ما يناسب الفاتورة. ولكن في الحقيقة ، الطريقة الوحيدة لمعرفة ذلك هي كتابة السيناريو بكل اللغات ومقارنة النتائج. انها كل شيء أكثر من الشعور الغريزي من اليقين. بعد بضع سنوات من كتابة النصوص ، ستكون قد صادفت "معظم أنواع المشاكل" ، وتعرف أي لغة تعمل بشكل جيد على حلها. - mkaito
أردت فقط أن أضيف أن استخدام برامج صغيرة في حزمة GNU coreutils (مثل tr، sort، uniq) وتوصيلها يمكن تحقيق الكثير من المهام. - GMaster


TL ؛ DR - استخدم باش فقط لتثبيت لغة أفضل (إذا لم تكن متوفرة بالفعل) ، وإلا فإنك تهدر الوقت البشري الثمين غير القابل للاسترداد. إذا كنت لا تستطيع أن تفعل ذلك على سطر الأوامر باليد دون أخطاء ، لا سكريبت مع باش / شل.

إنه عام 2015 ، لذلك سأفكر في ما يلي:

  1. الذاكرة العلوية

    • تعتبر ذاكرة روبي / بيثون وقت التشغيل مقارنة بباش صغيرة للغاية (بسبب المكتبات المشتركة) ، في حين أنه من المحتمل أن لا يتمكن المرء من الحفاظ على برنامج نصي bash غير عادي على أي حال (أي واحد مع أكثر من 100 سطر) - لذا فإن استخدام الذاكرة ليس عاملاً
  2. وقت بدء التشغيل

    • قد يكون بدء تشغيل Ruby / Python أبطأ قليلاً ، ولكن من المحتمل أنك لن تشغل الكثير من عمليات Ruby / Python الكاملة في حلقة ضيقة 100 مرة في الثانية (إذا كان لديك هذه الأنواع من الاحتياجات ، فإن bash / shell الكثير من النفقات العامة على أي حال ، وربما تحتاج إلى إسقاط إلى C / C ++)
  3. أداء

    • جميع تقلبات البيانات النموذجية تقريبًا ستكون أسرع في Ruby / Python - أو على الأقل قابلة للمقارنة (أو ، تحتاج C / C ++ / Haskel / OCaml / أيا كان على أي حال)
    • الأداء الحقيقي / عنق الزجاجة في التنفيذ (أو حتى الإنتاجية) سوف يكاد يكون ابدا يكون "عدم استخدام باش / شل" (حتى اندفاعة التبديل أوبونتو لبدء التشغيل يظهر كيف باش هو في الواقع المشكلة - وربما يكون صندوق الإزدحام هو حالة الاستخدام الوحيدة ، لأن هناك هو لا شيء أكثر من "bash" و "vi" لكتابة التعليمات البرمجية وتشغيلها ، وغالبًا ما لا توجد طريقة لإضافة / تنزيل أو تخزين أي شيء آخر)
    • تشغيل عمليات أخرى للقيام بهذه المهمة (مثل sed / awk / grep) هو في الواقع حجم أبطأ من استدعاء طريقة على كائن حي في الذاكرة
  4. إنتاجية

    • من السهل جدًا ارتكاب الأخطاء في Bash / shell مقارنةً باستخدام الأساليب "الحقيقية" والمعلمات والمتغيرات والاستثناءات في Ruby / Python
    • رشيق هو الاتجاه السائد ، في حين أن باش لا يدعمها (تفتقر إلى قدرات اختبار الوحدة ، المكتبات ، OO ، النمذجة ، التلصص ، الاستبطان ، قطع الأشجار ، التحليلات ؛ يكاد يكون من المستحيل أن تكون ريفاكتور بدون كسر شيء ما)
    • بسبب عدم توافق العديد من الأصداف الأخرى ، يمكن لمتغيرات البيئة البسيطة أن تكسر النص بالكامل (وبعض الأدوات المهمة مثل الدمى تتجاهل خطوط shebang وتمرير أو إعادة صياغة متغيرات shell الهامة) ، بينما يكون Ruby / Python بهجرة سلسة بشكل واضح نسبيًا مسارات حتى بالنسبة لتغييرات الإصدار الرئيسي
    • تعلم لغة جديدة تأخذ جزءًا من الوقت بدلاً من ذلك ، تصرف مخطوطات shell debugging نظرًا لوجود مشكلات خاصة بـ shell (خاصةً الأسماء المتغيرة ، لا booleans ، لا استثناءات ، إلخ.)
    • حتى النصوص البرمجية لبدء التشغيل هي لغم أرضي (خصوصا لأنها يمكن أن تفشل خلال النظام بدء التشغيل) ، وبالنظر إلى العيوب الأمنية الأخيرة مع bash ، قد يكون من الأفضل استخدام C عادي (مع مكتبات جيدة) - نعم ، يحتاج C إلى تجميع وتكوين ، وما إلى ذلك ، ولكن قد يحتاج حتى برنامج نصي صغير إلى مستودع ، ثم تعيين ، ثم التعبئة على أي حال.
    • كل ما هو متاح مع sed / awk / grep من المحتمل أن يكون قد تم بناؤه بالفعل في Ruby / Python - دون أن يكون ذلك تبعية أو "اختلافات" بين إصدارات تلك الأدوات عبر المنصات (فماذا إذا كان يعمل على ك اقامة)
  5. الأمن الوظيفي
    • ما الهدف من الحصول على وظيفة لا تحبها؟ (إلا إذا كنت تحب قضاء كل تلك الساعات التي يصعب تصويبها ولكن من الصعب فهمها

أجد أنه لا يوجد سبب لاستخدام Bash / Shell إذا كان لديك تثبيت Ruby / Python.

وربما لا يحتاج تثبيت Ruby / Python إلى برنامج نصي bash في المقام الأول (باستثناء برنامج busybox ، تعتمد بعض أدوات النظام على وجود Python / Perl على أي حال).

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

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

الاستنتاج: استخدم bash / shell فقط عندما تكون مطلقًا قسري لكى تحب ~/.bashrc، busybox) ، لأنه يكاد يكون أبدا "الأداة المناسبة لهذا المنصب" في الوقت الحاضر.


49
2017-07-04 13:59



أنا سعيد لشخص ما يوافق unix.stackexchange.com/questions/350266/... - Marco Prins


أستخدم bash عندما يكون تركيزي الأساسي على معالجة الملفات. قد يشمل ذلك نقل الملفات ونسخها وإعادة تسميتها ، وكذلك استخدام الملفات كمدخلات للبرامج الأخرى أو تخزين إخراج البرنامج الآخر في الملفات. نادرًا ما أكتب رمز bash الذي يفحص محتويات الملف أو يولد المخرجات للكتابة على الملف. أترك ذلك للبرامج الأخرى (التي قد أكتبها في Perl أو python) التي أقوم بتشغيلها عبر bash.

أستخدم Perl و python عندما يكون تركيزي الأساسي على قراءة البيانات من الملفات ، ومعالجة تلك البيانات بطريقة ما ، وكتابة الإخراج إلى الملفات. إذا وجدت نفسي باستخدام (في بيرل) system القيادة أو العودة القراد أو (في بيثون) subprocess وحدة على نطاق واسع جدا ، وأنا أفكر في كتابة السيناريو في باش. من ناحية أخرى ، أقوم في بعض الأحيان بإضافة الكثير من الوظائف إلى برنامج نصي bash الذي يجعل من الأفضل في نهاية الأمر إعادة كتابته في Perl / python بدلاً من التعامل مع دعم bash المحدود (مقارنة) للتحديد المتغير ، والوظائف ، وهياكل البيانات ، إلخ. .


27
2018-04-21 18:19



اعتدت t0 أيضا الكفالة على باش كلما كان مطلوبا ملف القراءة / توليد النص ، ولكن بعد تعلم =~ المشغل المدعوم من قبل [[ ]] لقد كنت محبا لي بعض باش ل بسيط قراءة الملف - Freedom_Ben


أنا أحب المعايير المنصوص عليها في هذا بلوق وظيفة.

  • إذا لم تكن هناك أي وسيطة لتمريرها ، فمن المحتمل أنها نص برمجي.
  • إذا لم يكن هناك الكثير لمنطق التحكم (إلى جانب حلقة واحدة أو إذا كان / else) ، فربما يكون نصًا شيلًا.
  • إذا كانت المهمة هي أتمتة تعليمات سطر الأوامر ، فمن المؤكد تقريبًا أنها نص برمجي.

14
2018-04-09 23:31





لقد وجدت هذا التحليل بيرل مقابل باش مفيدة ...

http://blogs.perl.org/users/buddy_burden/2012/04/perl-vs-shell-scripts.html

للراحة ، أنا نسخ ملخص ذلك المؤلف 1) عندما باش هو أفضل النتائج و 2) عندما بيرل هو استنتاج أفضل ...

عندما باش هو أفضل ...

  • فشل الوظيفة
  • أوامر على الخروج
  • تجهيز مخرجات مهمة
  • هنا الوثائق
  • معادلة الملف
  • مقارنات الطابع الزمني للملفات
  • توسيع تيلدا

عندما بيرل هو أفضل ...

بيرل لا يزال يتفوق على حماقة من باش لمعظم التطبيقات. أسباب قد تفضل بيرل تشمل (على سبيل المثال لا الحصر):

  • سيكون الأمر أسرع. يرجع السبب الرئيسي في ذلك إلى أنه لا يتعين عليّ في الواقع بدء عمليات جديدة للعديد من الأشياء التي أريد القيام بها (يكون الاسم الأساسي وأسم dirname هما المثالين الأكثر وضوحًا ، ولكن يمكن بشكل عام التخلص من كل من grep و sort و wc).
  • معالجة السلسلة في bash غير بدائية في أحسن الأحوال ، وكل شيء IFS $ هو عالي الكعب.
  • الشرطي في نصوص shell يمكن أن يكون غير واضح.
  • يمكن أن يكون نقلا في النصوص شل كابوسا.
  • يترك بيان حالة باش الكثير مما هو مطلوب بعد الحالات البسيطة (NPI).
  • صفائف في باش المص. اصطياد في باش (بافتراض أن bash الخاص بك هو جديد بما فيه الكفاية ليكون لها على الإطلاق) تمتص أكثر صعوبة.
  • بمجرد معالجة الملفات أو إخراج الأوامر تتجاوز الحالة البسيطة التي ذكرتها أعلاه ، يبدأ بيرل التدخين حقا باش.
  • CPAN.

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


8
2018-04-24 15:38



من المثير للاهتمام ، في روبي ، جميع النقاط (؟) لا تنطبق ، لأن روبي لديه at_exit () ، realpath () ، expand_path () ، stat () ، heredocs ، والاستثناءات (fail "error" unless system("foobar")). - Cezary Baginski


في تجربتي ، تعد bash versus python مقايضة بين وقت التطوير والمرونة. يمكن عادةً إنشاء حل بدائي للمشكلة بخط نصي bash بشكل أسرع مما يمكن أن يكون في نص python.

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

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


4
2017-09-30 15:42





Bash هو shell Unix يتضمن لغة برمجة. هو بالأحرى معالج الأوامر. يمكنك التحكم في طريقة تشغيل الأوامر ، فعليك تشغيلها بالفعل.

Perl / Ruby / Python هي لغات ذات أغراض عامة.

عندما تريد برنامج نصي shell ، يمكنك استخدام Bash

إذا كنت تريد مهمة أكثر تعقيدًا أو لا تتعلق بالقشرة. استخدم Python الخ

لن أقارن هذه اللغات أبداً. بايثون الخ هي محمولة. يمكنك تشغيلها في أي مكان. Bash مخصص لـ Unix فقط.

بيثون وما إلى ذلك لديها طن من المكتبات التي يعاد استخدامها في حل ملايين المهام.

انها نفسها تقريبا إذا سألت. "متى تستخدم" الرسام "ومتى تستخدم Photoshop"

لمعالجة رسائل البريد الإلكتروني ، استخدم روبي ، مرة أخرى ، لأنه يحتوي على الكثير من المكتبات التي يمكن إعادة استخدامها.

لكن أفضل طريقة هي الجمع بين باش و روبي. من شأنه أن يكون على حق. مثل إنشاء البرنامج النصي معالجة البريد الإلكتروني في البرنامج النصي ruby ​​وباش قد استدعاء هذا البرنامج النصي روبي وتشغيل commans أخرى س.

لذلك عندما تحتاج إلى معالج الأوامر ، يمكنك استخدام bash. يمكنك تشغيل أوامر يونيكس والتحكم فيها.


3
2018-04-21 03:03



المجموعة الفرعية لـ Bash هي غاية عامة مثل أي لغة برمجة نصية عامة. أضِف برامج عامة مثل برنامج Sed في هذا المزيج ، وغطيت نفسك بنسبة 90٪ من جميع احتياجات البرمجة النصية التي ستحصل عليها على الإطلاق. - mkaito
bash هو معالج أوامر ، لذا فإن قوته هي تشغيل أوامر وبرامج unix أخرى في نصوصهم .مثل ذكرك يا سيد الخ. وهو يسأل عن وقت اختيار لغة معينة - bakytn
القذيفة هي قاذفة برنامج مجيد في الواقع ، ولكن قدرات البرمجة هي أبعد من ذلك بكثير. أقترح عليك تعلم بعض البرامج النصية قذيفة حقيقية. - mkaito
أستطيع أن أنام على الأرض ولكنني أفضلها على السرير. اللغات لا يمكن مقارنتها لديهم أغراض dofferent. - bakytn
حسناً ، إذا كان باش هو الأرضية ، يجب أن يكون شيء مثل هاسكل لطلاء الأظافر :-) - mkaito


مقالة شديدة الانحياز.

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

أقوم بتشغيل نصوص bash على ملايين من تسلسلات DNA المتسلسلة في آلاف الملفات ، وهو ما يخدمني على ما يرام. وعلى عكس ما يقوله الجميع ، فإن نفس الإصدارات من النصوص في لغة C ++ لا تعمل في الواقع بشكل أسرع بكثير (في بضع دقائق تفصل بينها).

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


1
2017-11-09 21:09





من "كتاب اللاما"

  • راندال L. شوارتز ، توم فينيكس ، وبريان د فوي ، تعلم بيرل (سيباستوبول ، كاليفورنيا: أورايلي ، 2011) ، الفصل. 1.2 "ما الذي يمثله بيرل؟"، §§ "لماذا لم يكن لاري [خالق بيرل] مجرد استخدام بعض اللغات الأخرى؟" ، ص. 5:

يحاول Perl ملء الفجوة بين البرمجة ذات المستوى المنخفض (مثل C أو C ++ أو التجميع) والبرمجة عالية المستوى (مثل برمجة "shell" [على سبيل المثال ، bash]). عادةً ما يكون من الصعب كتابة البرامج منخفضة المستوى والقبيحة ، ولكنها سريعة وغير محدودة. من الصعب التغلب على سرعة برنامج منخفض المستوى مكتوب جيدًا على جهاز معين. وليس هناك الكثير لا يمكنك فعله هناك. البرمجة عالية المستوى ، في الطرف الآخر ، تميل إلى أن تكون بطيئة ، صلبة ، قبيحة ، ومحدودة ؛ هناك العديد من الأشياء التي لا يمكنك فعلها على الإطلاق باستخدام برمجة shell أو batch إذا لم يكن هناك أمر على نظامك يوفر الوظائف المطلوبة. Perl سهل ، غير محدود تقريبًا ، سريع في الغالب ، ونوع من القبيح.


0
2017-09-08 21:02





من المعروف أن نصوص Shell مثل bash و ksh و zsh و sh و fish تثير الدهشة ، مقارنةً باللغات ذات الأغراض العامة عالية المستوى مثل Ruby أو Python أو Perl. في حين أن برنامج نصي shell قد يبدأ حياته كملف أقصر من البرنامج النصي المكافئ للأغراض العامة ، فإن المفاجآت تؤدي إلى الكثير من كود الالتفاف الدفاعي ، مثل set -euo pipefail لتمكين أوضاع صارمة.

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


0
2017-07-09 07:17