Найкращі практики створення сценарію оболонки в GNU / Linux

Зазвичай, коли ви починаєте працювати над Область адміністрування серверів з операційними системами GNU / Linux та / або Unix, людина опиняється (працює) в середовищі, де зазвичай існує купу запланованих завдань, які писали інші адміністратори і що в якийсь момент ми повинні керувати (адмініструвати) пункт вирішити будь-яку проблему, вдосконалити та / або усунути, щоб виконати нову вимогу Установи де він працює. Тож не дивно, що якесь нове SysAdmin На будь-якому робочому місці перед вами стоїть громіздке завдання зрозуміти деякі з них Сценарій оболонки створені іншими старий SysAdmin, які погано написані, або мають логічну структуру чи структуру письма, їх непросто зрозуміти, або в гіршому випадку - командними командами, нетиповими, старими, неефективними або написаними незручним і заплутаним способом.

Сценарії ShellSi Bien вирішення погано написаних сценаріїв це завжди миттєва досада, це вчить кого завгодно хороший SysAdmin щось важливе. Якщо ви збираєтеся створити файл Сценарій оболонки користуватися не тільки сьогодні, це завжди краще пишіть їх дуже професійно та стандартизовано, щоб з часом будь-хто інший або хтось сам міг разом із мінімальні зусилля та знання забезпечують розуміння та адміністрування за мінімум часу.

Тому після практичної серії публікацій на тему "Дізнайтеся сценарії оболонки" де ми розглянемо декілька дуже практичних сценаріїв за допомогою простих та основних команд, ми почнемо з цієї нової серії "Найкращі практики створення сценарію оболонки в GNU / Linux", де ми ретельно зосередимось на кожному його маленькому аспекті та причині багатьох речей, тобто ми розглянемо кілька порад, які змусять нас робити кращі сценарії, але не стільки для себе, скільки для наступної людини (SysAdmin), повинен керувати ними. Тож вам не доведеться проходити нудне і важке завдання з’ясувати, що я кодую, як і чому і чому це більше не працює.

У цьому перший (1-й) пост цієї нової серії "Найкращі практики для хорошого сценарію оболонки для GNU / Linux" Ми поговоримо про те, що йде чи повинно йти в Заголовок сценарію оболонки.

=============================
ГОЛОВА - ЗАКЛИЧЕННЯ ОБЛІД
=============================

#! / шлях / інтерпретація [параметр-аргумент]

Верхній рядок - це основна структура, за допомогою якої запускається сценарій оболонки для GNU / Linux. Його елементи можна описати наступним чином:

#! => ша-баг

Ша-Банг (#!) у верхній частині сценарію, який створений або буде створений, є файл сценарій, який повідомляє нашій операційній системі, що наш файл - це набір команд, які будуть подані (будуть інтерпретовані) інтерпретатором команд, вказаним після нього. Пара персонажів #! насправді це магічне число двобайтовий, спеціальний маркер, який призначити тип файлу, а в нашому випадку, виконуваний сценарій оболонки. Одразу після ша-банга приходить назва шлях, де знаходиться інтерпретатор, який повинен бути виконаний, плюс ім'я згаданого інтерпретатора. Іншими словами, це шлях до програми, яка інтерпретує команди в сценарії, будь то інтерпретатор, мова програмування або утиліта. Потім ця оболонка виконує команди в сценарії, починаючи зверху (рядок після sha-bang), і ігноруючи коментарі. Дещо ша-банг вони можуть бути:

#! / Bin / ш
#! / бін / баш
#! / Usr / bin / perl
#! / usr / bin / tcl
#! / bin / sed -f
#! / usr / awk -f

Кожен з рядків, описаних вище (як приклад), викликає іншу оболонку. Лінія / Бен / ш, викликати оболонка за замовчуванням (Баш на операційній системі GNU / Linux) або інший подібний. Використовуючи #! / Bin / ш, значення за замовчуванням Борн Шелл У більшості комерційних варіантів операційних систем на базі UNIX це робить сценарій створеним портативний для інших операційних систем, які не працюють належним чином з Linux, але подібний або заснований на ньому або UNIX, хоча це жертвує специфічними характеристиками BASH. Однак послідовність "#! / Bin / sh" відповідає нормі Стандарт POSIX sh.

Зауважте, що шлях, вказаний у ша-банг, повинен бути правильним, в іншому випадку повідомлення про помилку, як правило "Команду не знайдено", це буде єдиним результатом виконання сценарію. Згадайте пару персонажів »#! « його можна опустити, якщо сценарій складається лише з набору загальних команд операційної системи, тобто без використання внутрішніх директив Shell. І ще раз майте на увазі, що »#! / Bin / sh« викликає інтерпретатор оболонки за замовчуванням, який за замовчуванням »#! / Bin / bash« в команді з ним Операційна система GNU / Linux.

Що стосується аргументів, можна використати кілька, але найпоширенішим є: »-E«. що робить сценарій перевірити помилки виконання будь-якої командиo (рядок виконання), а якщо позитивний, змушує зупинку і вихід, типовим є »-F« пункт вкажіть, який скрипт завантажити і одне з найрідкісніших »-Rm« що виконує його видалення після завершення його виконання. Це можна вказати лише в ша-банг до одиночний аргумент (параметр) після назви програми, яку потрібно виконати.

І наостанок, розкажіть сценарій глобальні змінні, які ви будете використовувати у важливих частинах коду, для перевірки подій, таких як шлях виконання, авторизований користувач, ім'я сценарію та ін. І закінчуємо на дані програми, творця, організації, серед іншого, плюс ліцензування, що стосується програми.

Моя порада (Кращі практики) вибрати найкращий ша-банг і заголовок a Сценарій оболонки звук:

#! / usr / bin / env bash

Навіщо використовувати команду »Env« Ми вказуємо Операційній системі інтерпретатор, який буде використовуватися з точним шляхом, вказаним у ньому за замовчуванням, що дозволяє нам мати ша-банг що збільшує його портативність, бо не у всіх ОС GNU / Linux перекладачі або програми мають однаковий шлях. І без аргументів, бо для цього краще використовувати команду комплект, тому що з ним ми можемо перевірити помилки, загальні (-e) або конкретні (+ x / -x), або до чіткі глобальні пресети для змінних середовища (-i) або конкретних (-u / –unset). І, нарешті, до виконувати конкретні (- о) взаємодоповнюючі дії всередині сценарію.

Отже, моїм рекомендованим HEADER буде:

#! / usr / bin / env bash
# Вкажіть інтерпретатор bash з абсолютним шляхом шляхом операційної системи.

встановити -o errexit
# Сказати сценарію зупинитися і закритись, коли команда або рядок виконання не вдаються.

встановити -o іменник
# Сказати сценарію зупинитися і закритись, коли сценарій намагається використовувати незадекларовані змінні.

set -o pipefail
# Отримати статус виходу останнього замовлення, яке повернуло ненульовий код виходу.

# встановити -o xtrace
# Для відстеження запущеного. Корисно для налагодження. Увімкніть його, щоб перевіряти лише помилки.

Не забудьте додатково дотримуватися цих рекомендацій:

01. - Вставте свій код: Зробити ваш код читабельним дуже важливо, і це те, про що багато людей, здається, також забувають. Спробуйте зробити необхідні відступи, щоб сприйняти хорошу логічну структуру в полі зору.

02. - Додайте пробіли між розділами коду: Це може допомогти зробити код набагато зрозумілішим, оскільки інтервал по модулях або розділах допомагає зробити код читабельним і простим для розуміння.

03. - Прокоментуйте якомога більше коду: Угорі (або внизу) кожного Порядку команд (рядок виконання) або розділу коду ідеально додати опис функції скриптів, щоб пояснити, що відбувається в самому коді.

04. - Створіть змінні з описовими назвами їх функцій: Призначте описові імена змінних, які очевидно ідентифікують функцію, для якої вона буде створена. Незважаючи на те, що ви створюєте тимчасові змінні, які ніколи не будуть використовуватися за межами одного блоку коду, все-таки добре вказати ім'я, яке неявно (об'єктивно) пояснює, які значення або функції він обробляє.

05. - Використовуйте синтаксис VARIABLE = $ (команда) для заміни команди: Якщо ви хочете створити змінну, значення якої походить від іншої команди, це можна зробити двома способами в bash. С зворотний тик, тобто з персонажами `` , Ейм: VARIABLE = `параметри команд-опцій`, але це вже застаріло, тому синтаксис VARIABLE = $ (команда) це найсучасніший, прийнятий і рекомендований спосіб. НІ -> ДАТА = `дата +% F` / ТАК -> ДАТА = $ (дата +% F)

06. - Використовуйте модулі та / або змінні перевірки суперкористувача та авторизованого користувача з паролем або без нього: Для підвищення рівня безпеки, якщо це необхідно.

07. - Використовуйте модулі та / або змінні перевірки операційної системи (дистрибутив, версія, архітектура): щоб запобігти використанню на непридатних платформах.

08. - Використовуйте модулі (процедури / розділи) для підтвердження виконання критичних або пакетних дій (модулі / функції): Звести до мінімуму помилки через імпровізацію або необережність.

09. - Надайте зручні інтерфейси (зручні для користувача): Терміналом з меню та кольорами з Діалог і Графічні інтерфейси для базових користувачів із Zenity, Gxmessage. І по можливості використовуйте підтримку ідентифікаційних звукових сповіщень про впізнавані події відповідно до звуку. Я намагався якомога більше, що може ваш сценарій працювати в обох напрямках, просто вмикаючи та вимикаючи опції / модулі / функції.

10.- Включіть модулі (повідомлення) «Привітання» та «Прощання»: у випадку необхідності підвищення інтерактивності з користувачем.

11. - Включити модуль перевірки подвійного виконання: Створіть для нього файл блокування, щоб запобігти його виконанню більше 1 разу одночасно.

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. Наприклад, у Debian (і, припускаю, тому Ubuntu):
    $ ls -l / bin / sh
    lrwxrwxrwx 1 кореневий корінь 4 aza 8 2014 / bin / sh -> тире
    Отже, оболонка за замовчуванням у Debian - тире. Дивіться тут: https://wiki.debian.org/Shell

  3.   безіменний - сказав він

    Як підказка про знання використовуваної оболонки:

    ехо $ 0
    echo $ SHELL
    env | grep ШЕЛК

  4.   Інж. Хосе Альберт - сказав він

    Ви справді праві! Я тестував на DEBIAN 9 та Kali Linux 2.0, і це правда! веде вас до тире. Тим більше рекомендація: #! / Usr / bin / env bash, якщо саме Shell ви хочете використовувати.

    І ви абсолютно праві, це shebang, але на деяких веб-сайтах (технічних літературах) вони називають це shabang або іншими словами, звідси моя плутанина. Приклад:

    Під час обчислень shebang - це послідовність символів, що складається із знака з номером символів та знака оклику (#!) На початку сценарію. Його також називають ша-банг, [1] [2] хешбанг, [3] [4] фунт-банг, [5] або хеш-плінг

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

    Y Розділ 2. Починаючи з Sha-Bang
    С: http://www.tldp.org/LDP/abs/html/sha-bang.html

  5.   Інж. Хосе Альберт - сказав він

    Також: базове ім'я $ 0