Praktikat më të mira për të krijuar një Shell Script në GNU / Linux

Zakonisht kur filloni të punoni në Zona e administrimit të serverave me GNU / Linux dhe / ose Sistemet Operative të Unix, dikush e gjen veten (përballet) duke punuar në një mjedis ku zakonisht ka një një bandë e detyrave të planifikuara që shkruajnë administratorët e tjerë dhe se në një moment ne duhet menaxho (administro) para zgjidhja e çdo problemi, përmirësimi dhe / ose eleminimi, në përputhje me një kërkesë të re të Institucionit ku ai punon. Kështu që nuk është e çuditshme, se ndonjë i ri SysAdmin Në çdo vend pune, ju jeni ballafaquar me detyrën e rëndë për të kuptuar disa nga ato Skenari i guaskës krijuar nga të tjerët i vjetër SysAdmin, që nuk janë shkruar mirë, ose janë në një strukturë logjike ose shkrimore, jo të lehtë për t’u kuptuar, ose në rastin më të keq, me komanda komanduese, atipike, të vjetra, joefikase, ose të shkruara në një mënyrë të vështirë dhe konfuze.

ndërsa zgjidhja e skenareve të shkruara dobët është gjithmonë një bezdi e çastit, kjo mëson këdo mir SysAdmin diçka e rëndësishme Nëse dikush do të krijojë një Skenari i guaskës të përdoret përtej sot, është gjithmonë më mirë shkruajini ato në një mënyrë shumë profesionale dhe të standardizuar, në mënyrë që me kalimin e kohës, çdokush tjetër, ose vetë, të mundet me përpjekje dhe njohuri minimale arrijnë kuptimin dhe administrimin në një minimum kohe.

Prandaj, pas serisë praktike të botimeve në "Mësoni Shell Scripting" ku shqyrtojmë disa skenarë shumë praktikë me komanda të thjeshta dhe themelore, do të fillojmë me këtë seri të re të quajtur "Praktikat më të mira për të krijuar një Shell Script në GNU / Linux", ku ne do të përqendrohemi plotësisht në secilin aspekt të tij dhe arsyen për shumë gjëra, domethënë, ne do të mbulojmë disa këshilla që do të na bëjnë të bëjmë skenare më të mira, por jo aq për veten tonë, por për personin tjetër (SysAdmin) që duhet t'i menaxhojë ato. Kështu që nuk keni pse të kaloni në detyrën e lodhshme dhe të vështirë për të kuptuar se çfarë kodoj, si dhe pse dhe pse nuk funksionon më.

Në këtë postimi i parë (i parë) të këtij seriali të ri "Praktikat më të mira për një Skript të mirë Shell për GNU / Linux" Ne do të flasim për atë që shkon ose duhet të shkojë në Titulli i Shell Script.

=======================================
KRYETARI - FTESA E SHELL
=======================================

#! / path / interpretoj [argument-parametër]

Vija e sipërme është struktura bazë me të cilën thirret një Shell Script për GNU / Linux. Elementet e tij mund të përshkruhen si më poshtë:

#! => sha-zhurmë

Sha-bang (#!) në krye të Shkrimit të krijuar ose që do të krijohet është një skenari që i tregon Sistemit tonë Operativ që skedari ynë është një grup komandash që do të ushqehen (do të interpretohen) nga interpretuesi i komandave i treguar pas tij. Çifti i personazheve #! në të vërtetë, është një numri magjik dy bajtësh, një shënues i veçantë që caktoni një lloj skedari, dhe në rastin tonë, një skenar i ekzekutueshëm shell. Menjëherë pas sha-bang vjen emri i rruga ku ndodhet interpretuesi që do të ekzekutohet plus emrin e përkthyesit të përmendur. Me fjalë të tjera, kjo është rruga drejt programit që interpreton komandat në skenar, qofshin ato një interpretues, një gjuhë programimi, ose një program tjetër. Kjo guaskë më pas ekzekuton komandat në skenar, duke filluar në krye (vija pas sha-bang), dhe duke injoruar çdo koment. Disa sha bang Ato mund të jenë:

# / Bin / sh
#! / bin / bash
#! / usr / bin / perl
#! / usr / bin / tcl
#! / bin / sed -f
#! / usr / awk -f

Secila nga linjat e përshkruara më sipër (si një shembull) thirr një predhë të ndryshme. Linja / Bin / sh, thirrni predhë sipas parazgjedhjes (Bash në një sistem operativ GNU / Linux) ose të tjera të ngjashme. Duke përdorur # / Bin / sh, vlera e paracaktuar e Guaska Bourne Në shumicën e varianteve komerciale të Sistemeve Operative të bazuara në UNIX, e bën Skriptin të krijuar i lëvizshëm për Sistemet e tjera Operative që nuk janë Linux siç duhet, por i ngjashëm ose i bazuar në të ose UNIX, megjithëse kjo sakrifikon karakteristikat specifike të BASH. Sidoqoftë, sekuenca "#! / Bin / sh" përputhet me normën POSIX sh standarde.

Tenga en cuenta que rruga e dhënë në sha-bang duhet të jetë e saktë, përndryshe një mesazh gabimi, zakonisht "Komanda nuk u gjet", do të jetë rezultati i vetëm i ekzekutimit të skenarit. Mos harroni çiftin e personazheve »#! « mund të hiqet nëse Skripti përbëhet vetëm nga një grup komandash gjenerike të Sistemit Operativ, domethënë pa përdorur direktiva të brendshme Shell. Dhe mbani në mend edhe një herë se »#! / Bin / sh« thërret interpretuesin e parazgjedhur të shell, i cili si standard »#! / Bin / bash« në një ekip me të Sistemi Operativ GNU / Linux.

Në lidhje me argumentet, ka disa që mund të përdoren, por më e zakonshmja është: »-E«. që e bën skenarin vërtetoni gabimet e ekzekutimit të çdo komandeo (vija e ekzekutimit) dhe nëse është pozitive, detyron ndalimin dhe daljen, një tipik është »-F« para tregoni se cilin skenar duhet të ngarkoni dhe një nga më të rrallat është »-Rm« që kryen fshirjen e tij pasi të ketë mbaruar ekzekutimi i tij. Possibleshtë e mundur të specifikohet vetëm në sha bang deri në argument i vetëm (parametër) pas emrit të programit për të ekzekutuar.

Dhe në fund, tregoni skenarin variablat globale që do të përdorni në pjesët thelbësore të kodit tuaj, për vërtetimin e ngjarjeve, të tilla si rruga e ekzekutimit, përdoruesi i autorizuar, emri i shkrimit, ndër të tjera. Dhe të përfundojë me të dhënat e programit, krijuesit, organizatës, ndër të tjera, plus licencimin që zbatohet për programin.

Këshillat e mia (Praktikat më të mira) për të zgjedhur sha-bang-i më i mirë dhe kreu a Skenari i guaskës shëndoshë:

#! / usr / bin / env bash

Pse përdor komandën? »Env« Ne i tregojmë Sistemit Operativ interpretin që do të përdoret me rrugën e saktë të specifikuar brenda tij si parazgjedhje, e cila na lejon të kemi një sha bang që rrit transportueshmërinë e tij, sepse jo në të gjitha OS GNU / Linux interpretuesit ose programet kanë të njëjtën rrugë. Dhe pa argumente, sepse për këtë është më mirë të përdorësh komandën i vendosur, sepse me të mundemi vërtetoni gabimet, të përgjithshme (-e) ose specifike (+ x / -x), ose te paracaktime të qarta globale për variablat e mjedisit (-i) ose specifike (-u / –unset). Dhe së fundmi, për të ekzekutoni veprime plotësuese specifike (- o) brenda skenarit.

Kështu që HEADER im i rekomanduar do të ishte:

#! / usr / bin / env bash
# Shënoni interpretuesin e bash me rrugën absolute nga Sistemi Operativ.

vendosur -o errexit
# Për t'i thënë skenarit të ndalet dhe të mbyllet kur dështon një komandë ose rresht ekzekutimi.

grup -o emër
# Për t'i thënë skriptit të ndalet dhe të mbyllet kur skenari përpiqet të përdorë variabla të padeklaruar.

vendosur -o tubfail
# Për të marrë statusin e daljes së porosisë së fundit që ktheu një kod daljeje pa zero.

# set -o xtrace
# Për të ndjekur atë që po ekzekutohet. E dobishme për korrigjimin e gabimeve. Aktivizoni atë për të kontrolluar vetëm për gabime.

Mos harroni të ndiqni gjithashtu këto rekomandime:

01. - Indente kodin tuaj: Bërja e kodit tuaj të lexueshëm është shumë e rëndësishme dhe është diçka që shumë njerëz duket se e harrojnë gjithashtu. Mundohuni të bëni indentacionet e nevojshme për të perceptuar një strukturë të mirë logjike në sy.

02. - Shtoni hapësira midis seksioneve të kodit: Kjo mund të ndihmojë që kodi të bëhet shumë më i kuptueshëm, pasi që ndarja sipas moduleve ose pjesëve ndihmon që kodi të lexohet dhe të kuptohet lehtë.

03.- Komentoni sa më shumë që të jetë e mundur në lidhje me kodin: Në krye (ose në fund) të secilit Urdhër Komandues (Rreshti i Ekzekutimit) ose Seksionit të Kodit, është ideale të shtoni një përshkrim të funksionit të skenarit (eve) për të shpjeguar se çfarë ndodh brenda vetë kodit.

04. - Krijoni variabla me emra përshkrues të funksioneve të tyre: Caktoni emra të variablave përshkrues që identifikojnë qartë funksionin për të cilin do të krijohet. Edhe pse krijoni variabla të përkohshëm që nuk do të përdoren kurrë jashtë një blloku të vetëm kodi, është akoma mirë të vendosni një emër që në mënyrë implicite (objektive) shpjegon se cilat vlera ose funksione trajton.

05. - Përdorni sintaksën VARIABLE = $ (komanda) për zëvendësimin e komandës: Nëse dëshironi të krijoni një ndryshore vlera e së cilës rrjedh nga një komandë tjetër, ka dy mënyra për ta bërë atë në bash. Me mbrapa, domethënë me personazhet " , P.sh.: VARIABLE = `komanda - parametrat e opsioneve`, por ajo është tashmë e amortizuar, pra sintaksa VARIABLE = $ (komanda) është mënyra më moderne, e pranuar dhe e rekomanduar. JO -> DATA = "data +% F" / PO -> DATA = $ (data +% F)

06. - Përdorni Superuser dhe Modulet e Autorizuara të Vlerësimit të Përdoruesit dhe / ose variablat me ose pa fjalëkalim: Për të rritur nivelet e sigurisë nëse është e nevojshme.

07.- Përdorni module dhe / ose ndryshore të Vlerësimit të Sistemit Operativ (Distro, Version, Arkitekturë): për të parandaluar përdorimin në platforma të papërshtatshme.

08. - Përdorni modulet (procedurat / seksionet) për të konfirmuar ekzekutimin e veprimeve kritike ose të grupeve (module / funksione): Për të minimizuar gabimet për shkak të improvizimit ose pakujdesisë.

09.- Siguroni ndërfaqe miqësore për përdoruesit (miqësore për përdoruesin): Nga Terminali me menu dhe ngjyra me dialog dhe Ndërfaqet grafike për përdoruesit bazë me Zenity, Gxmessage. Dhe nëse është e mundur përdorni mbështetjen e alarmeve zanore duke identifikuar ngjarje të njohura sipas zërit. Unë u përpoqa sa më shumë që të jetë e mundur që Shkrimi juaj të mundet punoni në të dy mënyrat vetëm duke mundësuar dhe paaftësuar opsionet / modulet / funksionet.

10.- Përfshini modulet (mesazhet) e Mirëseardhjes dhe Lamtumirës: nëse është e nevojshme për të rritur ndërveprimin me përdoruesin.

11.- Përfshini një modul të verifikimit të ekzekutimit të dyfishtë: Krijoni një skedar bllokimi për të që të mos ekzekutohet më shumë se 1 herë në të njëjtën kohë.

12.- Racionalizoni madhësinë e skenarit me funksione të jashtme dhe / ose module: Nëse Skripti është shumë i madh, ndani kodin duke përdorur funksione ose ndani ato në skripta të vegjël që thirren përmes një kryesor.

13.- Thirrja në një mënyrë të qartë dhe të qartë thirrjet drejt Interpretuesve të tjerë (gjuhët e programimit) brenda Shkrimit: Ftojini ato qartë sipas linjave ose moduleve.

Shembull:

# ================================================== #
#!/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.
# ======================================================= #
 

Në botimet e ardhshme ne do të zgjerojmë më në detaje secilën nga praktikat e përshkruara më sipër.

Dhe nëse dini disa praktika të tjera personale ose të tjera, mos hezitoni t'i komentoni ato për të bërë një përmbledhje më të plotë!

Deri në botimin e radhës të këtij seriali të ri.