أفضل الممارسات لإنشاء Shell Script في GNU / Linux

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

برمجة شل

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

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

Ebben أول (1) وظيفة من هذه السلسلة الجديدة "أفضل الممارسات لبرنامج Shell Script جيد لـ GNU / Linux" سنتحدث عما يحدث أو يجب أن يذهب في رأس البرنامج النصي لـ Shell.

=======================================
HEADER - فتنة قذيفة
=======================================

#! / مسار / تفسير [معامل-وسيطة]

السطر العلوي هو الهيكل الأساسي الذي من خلاله يتم استدعاء برنامج شل سكريبت لـ GNU / Linux. يمكن وصف عناصرها على النحو التالي:

#! => شا بانج

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

# / بن / ش
#! / بن / باش
#! / البيرة / بن / بيرل
#! / usr / bin / tcl
#! / bin / sed -f
#! / usr / awk -f

يستدعي كل سطر من الأسطر الموصوفة أعلاه (كمثال) غلافًا مختلفًا. الخط / بن / ش، واستدعاء قذيفة افتراضيا (Bash على نظام تشغيل GNU / Linux) أو ما شابه ذلك. باستخدام # / بن / ش، القيمة الافتراضية لـ بورن شل في معظم المتغيرات التجارية لأنظمة التشغيل المستندة إلى UNIX ، يتم إنشاء البرنامج النصي محمولة إلى أنظمة تشغيل أخرى ليست Linux بشكل صحيح، ولكنها تشبهها أو تستند إلى UNIX ، على الرغم من أن هذا يضحي بميزات خاصة بـ BASH. ومع ذلك ، فإن التسلسل "#! / Bin / sh" يتوافق مع القاعدة معيار POSIX sh.

لاحظ أن يجب أن يكون المسار الوارد في Sha-bang صحيحًا، أو تظهر رسالة خطأ عادةً "القيادة لم يتم العثور"، ستكون النتيجة الوحيدة لتنفيذ البرنامج النصي. تذكر زوج الشخصية »#! « يمكن حذفه إذا كان البرنامج النصي يتكون فقط من مجموعة من أوامر نظام التشغيل العامة ، أي بدون استخدام توجيهات Shell الداخلية. وتذكر مرة أخرى ذلك »#! / بن / ش« استدعاء مترجم الصدفة الافتراضي ، والذي يتم تعيينه افتراضيًا على »#! / بن / باش« في فريق معه نظام تشغيل جنو / لينكس.

فيما يتعلق بالحجج ، فهناك عدة حجج يمكن الاستعانة بها ولكن الأكثر شيوعاً: »-E«. مما يجعل النص تحقق من صحة أخطاء التنفيذ لأي أمرo (خط التنفيذ) وإذا كانت موجبة ، يفرض التوقف والخروج، النموذجي هو "-F" إلى الإشارة إلى البرنامج النصي المراد تحميله واحد من أندر »-Rm« يقوم بحذفه بمجرد الانتهاء من تنفيذه. من الممكن فقط أن تحدد في شا بانج حتى أ وسيطة واحدة (معلمة) بعد اسم البرنامج المراد تنفيذه.

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

نصيحتي (أفضل الممارسات) لاختيار أفضل شا بانغ والعنوان أ شيل هي:

#! / usr / bin / env bash

لماذا استخدام الأمر »Env« نشير إلى نظام التشغيل المترجم الذي سيتم استخدامه مع المسار الدقيق المحدد بداخله افتراضيًا ، مما يسمح لنا بالحصول على شا بانج مما يزيد من قابلية نقله ، لأنه ليس على الإطلاق OS GNU / Linux للمترجمين الفوريين أو البرامج نفس المسار. وبدون حجج ، لأنه من الأفضل استخدام الأمر طقملأننا معه نستطيع التحقق من صحة الأخطاء العامة (-e) أو الخاصة (+ x / -x)يا الفقرة إعدادات مسبقة عالمية واضحة للبيئة (-i) أو متغيرات محددة (-u / -unset). وأخيرا ، إلى تنفيذ إجراءات تكميلية محددة (- س) داخل البرنامج النصي.

لذلك سيكون HEADER الموصى به هو:

#! / usr / bin / env bash
# حدد مترجم bash بالمسار المطلق بواسطة نظام التشغيل.

مجموعة -o errexit
# لإخبار البرنامج النصي بالتوقف والخروج عند فشل الأمر أو سطر التنفيذ.

مجموعة -o nounset
# لإخبار البرنامج النصي بالتوقف والإغلاق عندما يحاول البرنامج النصي استخدام متغيرات غير معرّفة.

مجموعة -o pipefail
# للحصول على حالة الخروج من الأمر الأخير الذي أعاد رمز الخروج غير الصفري.

# مجموعة -o xtrace
# لتتبع ما يجري. مفيد في التصحيح. قم بتمكينه للتحقق من الأخطاء فقط.

تذكر أيضًا اتباع هذه التوصيات:

01.- إندينتي الكود الخاص بك: من المهم جدًا جعل الكود الخاص بك قابلاً للقراءة ، ويبدو أن الكثير من الناس ينسونه أيضًا. حاول عمل المسافات البادئة اللازمة لإدراك بنية منطقية جيدة في الأفق.

02.- إضافة مسافات بين أقسام الكود: يمكن أن يساعد ذلك في جعل الكود أكثر قابلية للفهم ، لأن التباعد حسب الوحدات أو الأقسام يساعد في جعل الكود قابلاً للقراءة وسهل الفهم.

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

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

05.- استخدم صيغة VARIABLE = $ (أمر) لاستبدال الأمر: إذا كنت تريد إنشاء متغير تكون قيمته مشتقة من أمر آخر ، فهناك طريقتان للقيام بذلك في bash. مع القراد الخلفي، وهذا هو ، مع الشخصيات " , EJM: VARIABLE = "معلمات خيارات الأوامر"، لكنها مهملة بالفعل ، لذا فإن بناء الجملة VARIABLE = $ (أمر) إنها الطريقة الأكثر حداثة والمقبولة والموصى بها. لا -> التاريخ = `التاريخ +٪ F` / نعم -> التاريخ = $ (التاريخ +٪ F)

06.- استخدام وحدات و / أو متغيرات التحقق من صحة المستخدم المتميز والمستخدم المعتمد بكلمة مرور أو بدونها: لزيادة مستويات الأمان إذا لزم الأمر.

07.- استخدام وحدات و / أو متغيرات التحقق من صحة نظام التشغيل (Distro ، الإصدار ، العمارة): لمنع الاستخدام على منصات غير مناسبة.

08.- استخدم الوحدات النمطية (الإجراءات / الأقسام) لتأكيد تنفيذ الإجراءات الحرجة أو الدفعية (الوحدات / الوظائف): لتقليل الأخطاء الناتجة عن الارتجال أو الإهمال.

09.- توفير واجهات سهلة الاستخدام (سهلة الاستخدام): بواسطة المحطة الطرفية مع القوائم والألوان مع حوار و واجهات رسومية للمستخدمين الأساسيين مع Zenity ، Gxmessage. وإذا أمكن ، استخدم دعم التنبيهات الصوتية المعرفية للأحداث التي يمكن التعرف عليها وفقًا للصوت. حاولت قدر الإمكان أن البرنامج النصي الخاص بك العمل في كلا الاتجاهين فقط عن طريق تمكين وتعطيل الخيارات / الوحدات / الوظائف.

10.- تضمين وحدات الترحيب والوداع (الرسائل): إذا لزم الأمر لزيادة التفاعل مع المستخدم.

11.- تضمين وحدة التحقق من تنفيذ مزدوج: قم بإنشاء ملف قفل له لمنع تنفيذه أكثر من مرة واحدة في نفس الوقت.

12.- ترشيد حجم البرنامج النصي باستخدام وظائف و / أو وحدات خارجية: إذا كان البرنامج النصي كبيرًا جدًا ، فقسِّم الشفرة باستخدام الوظائف أو قسِّمها إلى نصوص برمجية صغيرة يتم استدعاؤها من خلال واحدة رئيسية.

13.- الاستدعاء بشكل واضح وواضح للنداءات للمترجمين الآخرين (لغات البرمجة) داخل النص: يستدعيهم بوضوح من خلال الخطوط أو الوحدات.

على سبيل المثال:

# ================================================== #
#!/bin/bash
#Llamando a un interprete externo a BASH
echo 'El siguiente texto será mostrado por el interprete de PERL'
perl -e 'print "Este texto es mostrado por un script PERL embebido.\n";'
exit 0
# ==================================================#
# ==================================================# 
#!/bin/bash #Llamando al interprete de Python. 
echo 'El siguiente es un script de python:'
echo print "Hola, mundo!" | tee $HOME/.testpythonbash.py
python $HOME/.testpythonbash.py exit 0
# ==================================================#

# ======================================================= #
#!/bin/bash
# bash-y-perl.sh

echo "Saludos desde la parte BASH del script."
# Es posible añadir mas comandos BASH aqui.

exit 0
# Fin de la parte BASH del script.

###########################################################

#!/usr/bin/perl
# Esta parte del script se invoca con la opcion -x.

print "Saludos desde la parte PERL del script.\n";
# Podemos añadir mas comandos PERL aqui.

# Fin de la parte PERL del script.
# ======================================================= #
 

في المنشورات المستقبلية سوف نتوسع بمزيد من التفصيل في كل من الممارسات المذكورة أعلاه.

وإذا كنت تعرف بعض الممارسات الجيدة الأخرى ، الخاصة بك أو غيرها ، فلا تتردد في التعليق عليها لإعداد خلاصة وافية أكثر اكتمالاً!

حتى النشر التالي لهذه السلسلة الجديدة.


6 تعليقات ، اترك لك

اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها ب *

*

*

  1. المسؤول عن البيانات: ميغيل أنخيل جاتون
  2. الغرض من البيانات: التحكم في الرسائل الاقتحامية ، وإدارة التعليقات.
  3. الشرعية: موافقتك
  4. توصيل البيانات: لن يتم إرسال البيانات إلى أطراف ثالثة إلا بموجب التزام قانوني.
  5. تخزين البيانات: قاعدة البيانات التي تستضيفها شركة Occentus Networks (الاتحاد الأوروبي)
  6. الحقوق: يمكنك في أي وقت تقييد معلوماتك واستعادتها وحذفها.

  1.   ماكس جي رودريغيز قال

    تفصيل واحد فقط ، إنها "شيبانج" 😛
    مشاركة جيدة جدًا ، تساعد الممارسات الجيدة على المدى الطويل دائمًا في التوحيد.

  2.   واحد مر هنا قال

    Bash ليست الصدفة الافتراضية في جميع التوزيعات ، وبالتالي فإن الرابط / bin / sh الرمزي لا يشير دائمًا إلى bash. في دبيان على سبيل المثال (وأفترض بالتالي أن أوبونتو):
    $ ls -l / bin / sh
    lrwxrwxrwx 1 root root 4 aza 8 2014 / bin / sh -> dash
    وبالتالي فإن الغلاف الافتراضي في دبيان هو dash. انظر هنا: https://wiki.debian.org/Shell

  3.   مجهول قال

    كنصيحة لمعرفة شل قيد الاستخدام:

    صدى $ 0
    صدى $ شل
    env | grep شل

  4.   المهندس خوسيه ألبرت قال

    أنت محق بالفعل! لقد اختبرت على DEBIAN 9 و Kali Linux 2.0 وهذا صحيح! يأخذك إلى الاندفاع. والأكثر من ذلك أن التوصية: #! / Usr / bin / env bash إذا كانت شل هي التي تريد استخدامها.

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

    في الحوسبة ، shebang هو تسلسل الأحرف الذي يتكون من علامة رقم الأحرف وعلامة التعجب (#!) في بداية البرنامج النصي. يطلق عليه أيضًا اسم sha-bang ، [1] [2] hashbang ، [3] [4] pound-bang ، [5] أو hash-pling

    من: https://en.wikipedia.org/wiki/Shebang_%28Unix%29

    الفصل Y 2. البدء بـ Sha-Bang
    من: http://www.tldp.org/LDP/abs/html/sha-bang.html

  5.   المهندس خوسيه ألبرت قال

    أيضا: basename $ 0