Bästa metoder för att skapa ett Shell-skript i GNU / Linux

Vanligtvis när du börjar arbeta med Administrationsområde för servrar med operativsystem GNU / Linux och / eller Unix, man befinner sig (ansikten) arbetar i en miljö där det vanligtvis finns en massa schemalagda uppgifter som andra administratörer skrev och att vi någon gång måste hantera (administrera) till lösa alla problem, förbättra och / eller eliminera, för att uppfylla ett nytt krav från institutionen där han arbetar. Så det är inte konstigt att något nytt SysAdmin På alla arbetsplatser står du inför den besvärliga uppgiften att förstå några av de Skalskript skapad av andra gamla SysAdmin, som inte är välskrivna eller har en logisk eller skriftlig struktur, inte lätt att förstå eller i värsta fall med kommandokommandon, atypiska, gamla, ineffektiva eller skrivna på ett besvärligt och förvirrande sätt.

Shell-skript

lösa dåligt skrivna manus är alltid en tillfällig irritation, det lär alla bra SysAdmin något viktigt. Om man ska skapa en Skalskript att användas bortom idag, är alltid bättre skriv dem på ett mycket professionellt och standardiserat sätt, så att över tid, någon annan, eller en själv, kan med minimal ansträngning och kunskap uppnår förståelse och administration på ett minimum av tid.

Därför, efter den praktiska publikationsserien på "Lär dig Shell Scripting" där vi undersöker några mycket praktiska skript med enkla och grundläggande kommandon, börjar vi med den här nya serien som heter "Bästa metoder för att skapa ett Shell-skript i GNU / Linux", där vi grundligt kommer att fokusera på varje liten aspekt av det och anledningen till många saker, det vill säga vi kommer att täcka några tips som får oss att göra bättre manus, men inte så mycket för oss själva, men för nästa person (SysAdmin) som måste hantera dem. Så du behöver inte gå igenom den tråkiga och svåra uppgiften att ta reda på vad jag kodar, hur och varför och varför det inte längre fungerar.

I detta första (första) inlägget av denna nya serie "Bästa praxis för ett bra Shell-skript för GNU / Linux" Vi kommer att prata om vad som går eller ska gå i Rubrik för Shell Script.

=======================================
HEADER - INBJUDAN PÅ SKALET
=======================================

#! / path / interpret [parameter-argument]

Den översta raden är den grundläggande strukturen som ett Shell Script för GNU / Linux åberopas. Dess element kan beskrivas enligt följande:

#! => sha-bang

Sha-bang (#!) högst upp i skriptet som skapats eller skapas finns en skript som berättar för vårt operativsystem att vår fil är en uppsättning kommandon som matas (tolkas) av kommandotolken som anges efter den. Karaktärsparet #! faktiskt är det en magiskt nummer två-byte, en speciell markör som ange en filtyp, och i vårt fall, ett körbart skalskript. Omedelbart efter sha-bang kommer namnet på sökvägen där tolk som ska exekveras ligger plus namnet på nämnda tolk. Med andra ord är detta vägen till programmet som tolkar kommandona i skriptet, oavsett om det är en tolk, ett programmeringsspråk eller ett verktyg. Detta skal kör sedan kommandona i skriptet, från början (raden efter sha-bang) och ignorerar eventuella kommentarer. Några sha bang de kan vara:

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

Var och en av raderna som beskrivs ovan (som ett exempel) åberopar ett annat skal. Linjen / Bin / sh, åberopa skal som standard (Bash på ett GNU / Linux-operativsystem) eller liknande. Använder sig av #! / Bin / sh, standardvärdet för Bourne skal I de flesta kommersiella varianter av UNIX-baserade operativsystem gör det skriptet skapat bärbar till andra operativsystem som inte är Linux korrekt, men liknande eller baserat på det eller UNIX, även om detta offrar specifika egenskaper hos BASH. Men sekvensen "#! / Bin / sh" överensstämmer med normen POSIX sh standard.

Tänk på det den väg som ges i sha-bang måste vara korrekt, annars ett felmeddelande, vanligtvis "Kommando inte hittat"kommer det att vara det enda resultatet av skriptkörningen. Kom ihåg karaktärsparet »#! « Det kan utelämnas om skriptet endast består av en uppsättning generiska operativsystemskommandon, det vill säga utan att använda interna Shell-direktiv. Och kom ihåg det igen »#! / Bin / sh« åberopar standardskiltolken, som standard är »#! / Bin / bash« i ett team med honom GNU / Linux operativsystem.

När det gäller argumenten finns det flera som kan användas men det vanligaste är: »-E«. vilket gör manuset validera körningsfelen för alla kommandono (utförandelinje) och om det är positivt, tvingar stopp och utgång, en typisk är »-F« till ange vilket skript som ska laddas och en av de sällsynta är »-Rm« som utför raderingen av den när dess körning är klar. Det är bara möjligt att specificera i sha bang tills a enda argument (parameter) efter namnet på programmet som ska köras.

Och slutligen berätta manuset de globala variablerna du kommer att använda i väsentliga delar av din kod, för validering av händelser, som exekveringsväg, auktoriserad användare, skriptnamn, bland andra. Och sluta med data från programmet, skapare, organisation, bland annat plus licensiering som gäller för programmet.

Mitt råd (bästa metoder) att välja bästa sha-bang och rubrik a Skalskript ljud:

#! / usr / bin / env bash

Varför använda kommandot »Env« Vi anger för operativsystemet tolk som ska användas med den exakta sökvägen som anges som standard, vilket gör att vi kan ha en sha bang som ökar bärbarheten av det, för inte alls OS GNU / Linux tolkar eller program har samma väg. Och utan argument, för det är det bättre att använda kommandot in, för med honom kan vi validera fel, allmänt (-e) eller specifikt (+ x / -x), O para rensa globala förinställningar för miljövariabler (-i) eller specifika (-u / –unset) variabler. Och slutligen, till genomföra specifika (- o) kompletterande åtgärder inuti skriptet.

Så min rekommenderade HEADER skulle vara:

#! / usr / bin / env bash
# Ange bash-tolk med absolut sökväg med operativsystem.

set -o errexit
# Att berätta för skriptet att stoppa och stänga när ett kommando eller en exekveringsrad misslyckas.

set -o substantivuppsättning
# Att berätta för skriptet att stoppa och stänga när skriptet försöker använda odeklarerade variabler.

set -o pipefail
# För att få utgångsstatus för den sista beställningen som returnerade en utgångskod som inte är noll.

# set -o xtrace
# För att spåra vad som körs. Användbar för felsökning. Aktivera det för att bara kontrollera om det finns fel.

Kom ihåg att också följa dessa rekommendationer:

01.- Rikta in din kod: Att göra din kod läsbar är mycket viktig, och det är något som många tycks glömma också. Försök göra nödvändiga fördjupningar för att uppfatta en bra logisk struktur i sikte.

02.- Lägg till separationsavstånd mellan kodsektionerna: Detta kan hjälpa till att göra koden mycket mer förståelig, eftersom avståndet mellan moduler eller sektioner gör koden läsbar och lätt att förstå.

03.- Kommentera så mycket som möjligt om koden: Längst upp (eller längst ner) i varje kommandorad (utförandelinje) eller kodavsnitt är det idealiskt att lägga till en beskrivning av funktionerna för skriptet (erna) för att förklara vad som händer i själva koden.

04. - Skapa variabler med beskrivande namn på deras funktioner: Tilldela beskrivande variabelnamn som uppenbarligen identifierar den funktion för vilken den kommer att skapas. Även om du skapar tillfälliga variabler som aldrig kommer att användas utanför ett enda kodblock är det fortfarande bra att sätta ett namn som implicit (objektivt) förklarar vilka värden eller funktioner det hanterar.

05. - Använd syntaxen VARIABLE = $ (kommando) för kommandosubstitution: Om du vill skapa en variabel vars värde härrör från ett annat kommando finns det två sätt att göra det i bash. Med tillbaka bock, det vill säga med karaktärerna '' , EJM: VARIABLE = `kommando-alternativparametrar`, men det är redan föråldrat, så syntaxen VARIABLE = $ (kommando) det är det mest moderna, accepterade och rekommenderade sättet. NEJ -> DATUM = `datum +% F` / JA -> DATUM = $ (datum +% F)

06.- Använd Superuser och auktoriserade användarvalideringsmoduler och / eller variabler med eller utan lösenord: För att öka säkerhetsnivåerna vid behov.

07.- Använd moduler och / eller variabler för validering av operativsystemet (Distro, version, arkitektur): för att förhindra användning på olämpliga plattformar.

08.- Använd moduler (procedurer / avsnitt) för att bekräfta utförandet av kritiska eller batchåtgärder (moduler / funktioner): För att minimera misstag på grund av improvisation eller slarv.

09. - Ge användarvänliga gränssnitt (användarvänligt): Vid terminal med menyer och färger med dialogruta och Grafiska gränssnitt för basanvändare med Zenity, Gxmessage. Och använd om möjligt stöd för identifieringsljudvarningar om igenkännliga händelser enligt ljudet. Jag försökte så mycket som möjligt att ditt skript kan arbeta båda vägarna bara genom att aktivera och inaktivera alternativ / moduler / funktioner.

10. - Inkludera välkomst- och farvälsmoduler (meddelanden): om det behövs för att öka interaktiviteten med användaren.

11. - Inkludera en verifieringsmodul för dubbel utförande: Skapa en låsfil för den för att förhindra att den körs mer än en gång samtidigt.

12.- Rationalisera storleken på skriptet med externa funktioner och / eller moduler: Om skriptet är mycket stort, dela upp koden med hjälp av funktioner eller dela dem i små skript som anropas genom en huvudkod.

13. - Anrop på ett tydligt och tydligt sätt samtal till andra tolkar (programmeringsspråk) inom skriptet: Bjud in dem tydligt med linjer eller moduler.

Exempelvis:

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

I framtida publikationer kommer vi att utöka mer i detalj var och en av de metoder som beskrivs ovan.

Och om du känner till andra goda metoder, din egen eller andra, tveka inte att kommentera dem för att göra ett mer komplett kompendium!

Fram till nästa publicering av denna nya serie.


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   Max j ​​rodriguez sade

    Bara en detalj, det är "shebang" 😛
    mycket bra inlägg, god praxis på lång sikt hjälper alltid till att standardisera.

  2.   En som passerade här sade

    Bash är inte standardskalet på alla distributioner, och därför pekar inte symbolen / bin / sh alltid på bash. I Debian till exempel (och jag antar därför Ubuntu):
    $ ls -l / bin / sh
    lrwxrwxrwx 1 root root 4 aza 8 2014 / bin / sh -> dash
    Standardskalet på Debian är därför streck. Kolla här: https://wiki.debian.org/Shell

  3.   namnlös sade

    Som ett tips för att känna till Shell i användning:

    eko $ 0
    eko $ SHELL
    skicka | grep SHELL

  4.   Ing. José Albert sade

    Du har verkligen rätt! Jag försökte DEBIAN 9 och Kali Linux 2.0 och det är sant! tar dig till streck. Ännu mer så rekommendationen från: #! / Usr / bin / env bash om det är Shell som du vill använda.

    Och du har helt rätt att det är shebang, men på vissa webbplatser (tekniska litteraturer) kallar de det shabang eller andra ord, därav min förvirring. Exempel:

    I databehandling är en shebang teckensekvensen som består av teckensiffran och utropstecknet (#!) I början av ett skript. Det kallas också sha-bang, [1] [2] hashbang, [3] [4] pund-bang, [5] eller hash-pling

    från: https://en.wikipedia.org/wiki/Shebang_%28Unix%29

    Y Kapitel 2. Börja med en Sha-Bang
    från: http://www.tldp.org/LDP/abs/html/sha-bang.html

  5.   Ing. José Albert sade

    Också: basnamn $ 0