Perché scrivere un intero script bash in funzioni?

Al lavoro, scrivo spesso script di bash. Il mio supervisore ha suggerito che l'intero script sia suddiviso in funzioni, simile al seguente esempio:

#!/bin/bash

# Configure variables
declare_variables() {
    noun=geese
    count=three
}

# Announce something
i_am_foo() {
    echo "I am foo"
    sleep 0.5
    echo "hear me roar!"
}

# Tell a joke
walk_into_bar() {
    echo "So these ${count} ${noun} walk into a bar..."
}

# Emulate a pendulum clock for a bit
do_baz() {
    for i in {1..6}; do
        expr $i % 2 >/dev/null && echo "tick" || echo "tock"
        sleep 1
    done
}

# Establish run order
main() {
    declare_variables
    i_am_foo
    walk_into_bar
    do_baz
}

main

C'è qualche motivo per farlo oltre alla "leggibilità", che penso possa essere ugualmente ben stabilita con qualche commento in più e qualche interlinea?

Rende l'esecuzione dello script più efficiente (in realtà mi aspetterei il contrario, se non altro) o semplifica la modifica del codice oltre il suddetto potenziale di leggibilità? O è davvero solo una preferenza stilistica?

Si noti che sebbene lo script non lo dimostri bene, l '"ordine di esecuzione" delle funzioni nei nostri script effettivi tende ad essere molto lineare - walk_into_bardipende dalle cose che i_am_fooha fatto e do_bazagisce sulle cose impostate da walk_into_bar- così essendo in grado di scambiare arbitrariamente l'ordine di esecuzione non è qualcosa che faremmo generalmente. Per esempio, non si improvvisamente voglia di mettere declare_variablesdopo walk_into_bar, che rompere le cose.

Un esempio di come scriverei lo script sopra sarebbe:

#!/bin/bash

# Configure variables
noun=geese
count=three

# Announce something
echo "I am foo"
sleep 0.5
echo "hear me roar!"

# Tell a joke
echo "So these ${count} ${noun} walk into a bar..."

# Emulate a pendulum clock for a bit
for i in {1..6}; do
    expr $i % 2 >/dev/null && echo "tick" || echo "tock"
    sleep 1
done

Ho iniziato a usare lo stesso stile di programmazione bash dopo aver letto il post sul blog di Kfir Lavi "Defensive Bash Programming" . Dà alcuni buoni motivi, ma personalmente trovo questi i più importanti:

• le procedure diventano descrittive: è molto più facile capire cosa dovrebbe fare una parte particolare del codice. Invece di wall of code, vedi "Oh, la find_log_errorsfunzione legge quel file di registro per errori". Confrontalo con la ricerca di un sacco di righe awk / grep / sed che usano god sa quale tipo di regex nel mezzo di un lungo script - non hai idea di cosa ci faccia a meno che non ci siano commenti.

• è possibile eseguire il debug delle funzioni racchiudendo in set -xe set +x. Una volta che sai che il resto del codice funziona bene, puoi usare questo trucco per concentrarti solo sul debug di quella specifica funzione. Certo, puoi racchiudere parti della sceneggiatura, ma se fosse una porzione lunga? È più facile fare qualcosa del genere:

   set -x
   parse_process_list
   set +x

• utilizzo della stampa con cat <<- EOF . . . EOF. L'ho usato parecchie volte per rendere il mio codice molto più professionale. Inoltre, parse_args()con la getoptsfunzione è abbastanza conveniente. Ancora una volta, questo aiuta con la leggibilità, invece di inserire tutto nella sceneggiatura come un gigantesco muro di testo. È anche conveniente riutilizzarli.

E ovviamente, questo è molto più leggibile per qualcuno che conosce C o Java, o Vala, ma ha un'esperienza bash limitata. Per quanto riguarda l'efficienza, non c'è molto che puoi fare: bash stesso non è il linguaggio più efficiente e le persone preferiscono il perl e il pitone quando si tratta di velocità ed efficienza. Tuttavia, è possibile niceuna funzione:

nice -10 resource_hungry_function

Rispetto a chiamare nice su ogni singola riga di codice, ciò riduce un sacco di digitazione E può essere comodamente utilizzato quando si desidera che solo una parte dello script venga eseguita con priorità inferiore.

L'esecuzione di funzioni in background, a mio avviso, aiuta anche quando vuoi avere un sacco di istruzioni da eseguire in background.

Alcuni degli esempi in cui ho usato questo stile:

• https://askubuntu.com/a/758339/295286
• https://askubuntu.com/a/788654/295286
• https://github.com/SergKolo/sergrep/blob/master/chgreeterbg.sh

La leggibilità è una cosa. Ma c'è di più nella modularizzazione oltre a questo. (La semi-modularizzazione è forse più corretta per le funzioni.)

Nelle funzioni è possibile mantenere alcune variabili locali, il che aumenta l' affidabilità , diminuendo la possibilità che si verifichino errori.

Un altro pro di funzioni è la riutilizzabilità . Una volta codificata, una funzione può essere applicata più volte nello script. Puoi anche portarlo su un altro script.

Il tuo codice ora potrebbe essere lineare, ma in futuro potresti entrare nel regno del multi-threading o del multi-processing nel mondo Bash. Una volta che imparerai a fare le cose con le funzioni, sarai ben equipaggiato per entrare nel parallelo.

Un altro punto da aggiungere. Come osserva Etsitpab Nioliv nel commento qui sotto, è facile reindirizzare dalle funzioni come entità coerente. Ma c'è un altro aspetto dei reindirizzamenti con funzioni. Vale a dire, i reindirizzamenti possono essere impostati lungo la definizione della funzione. Per esempio.:

f () { echo something; } > log

Ora non sono necessari reindirizzamenti espliciti dalle chiamate di funzione.

$ f

Questo può risparmiare molte ripetizioni, il che aumenta di nuovo l'affidabilità e aiuta a mantenere le cose in ordine.

Guarda anche

• https://unix.stackexchange.com/a/483304/181255

Nel mio commento, ho citato tre vantaggi delle funzioni:

1. Sono più facili da testare e verificare la correttezza.

2. Le funzioni possono essere facilmente riutilizzate (provenienti) in script futuri

3. Al tuo capo piacciono.

E non sottovalutare mai l'importanza del numero 3.

Vorrei affrontare un altro problema:

... quindi essere in grado di scambiare arbitrariamente l'ordine di esecuzione non è qualcosa che faremmo generalmente. Per esempio, non si improvvisamente voglia di mettere declare_variablesdopo walk_into_bar, che rompere le cose.

Per ottenere il vantaggio di suddividere il codice in funzioni, si dovrebbe cercare di rendere le funzioni il più indipendenti possibile. Se walk_into_barrichiede una variabile che non viene utilizzata altrove, tale variabile deve essere definita e resa locale walk_into_bar. Il processo di separazione del codice in funzioni e di riduzione al minimo delle loro interdipendenze dovrebbe rendere il codice più chiaro e semplice.

Idealmente, le funzioni dovrebbero essere facili da testare individualmente. Se, a causa delle interazioni, non sono facili da testare, allora questo è un segno che potrebbero beneficiare del refactoring.

Rompi il codice in funzioni per lo stesso motivo per cui lo faresti per C / C ++, python, perl, ruby ​​o qualunque altro codice del linguaggio di programmazione. La ragione più profonda è l'astrazione: incapsuli le attività di livello inferiore in primitive (funzioni) di livello superiore in modo da non doverti preoccupare di come vengono fatte le cose. Allo stesso tempo, il codice diventa più leggibile (e gestibile) e la logica del programma diventa più chiara.

Tuttavia, guardando il tuo codice, trovo abbastanza strano avere una funzione per dichiarare le variabili; questo mi fa davvero alzare un sopracciglio.

Mentre sono totalmente d'accordo con la riusabilità , la leggibilità e il bacio delicato dei capi, ma c'è un altro vantaggio delle funzioni in bash : portata variabile . Come mostra LDP :

#!/bin/bash
# ex62.sh: Global and local variables inside a function.

func ()
{
  local loc_var=23       # Declared as local variable.
  echo                   # Uses the 'local' builtin.
  echo "\"loc_var\" in function = $loc_var"
  global_var=999         # Not declared as local.
                         # Therefore, defaults to global. 
  echo "\"global_var\" in function = $global_var"
}  

func

# Now, to see if local variable "loc_var" exists outside the function.

echo
echo "\"loc_var\" outside function = $loc_var"
                                      # $loc_var outside function = 
                                      # No, $loc_var not visible globally.
echo "\"global_var\" outside function = $global_var"
                                      # $global_var outside function = 999
                                      # $global_var is visible globally.
echo                      

exit 0
#  In contrast to C, a Bash variable declared inside a function
#+ is local ONLY if declared as such.

Non lo vedo molto spesso negli script di shell del mondo reale, ma sembra una buona idea per script più complessi. Ridurre la coesione aiuta a evitare bug nei casi in cui stai bloccando una variabile prevista in un'altra parte del codice.

Riusabilità spesso significa creare una libreria comune di funzioni e sourceinserire quella libreria in tutti i tuoi script. Questo non li aiuterà a correre più velocemente, ma ti aiuterà a scriverli più velocemente.

Un motivo completamente diverso da quelli già indicati in altre risposte: uno dei motivi per cui questa tecnica viene talvolta utilizzata, in cui l'unica affermazione di non funzione al primo livello è una chiamata a main, è assicurarsi che lo script non faccia accidentalmente nulla di brutto se lo script viene troncato. Lo script può essere troncato se viene reindirizzato dal processo A al processo B (shell) e il processo A termina per qualsiasi motivo prima di aver finito di scrivere l'intero script. Ciò è particolarmente probabile che accada se il processo A recupera lo script da una risorsa remota. Mentre per motivi di sicurezza non è una buona idea, è qualcosa che viene fatto e alcuni script sono stati modificati per anticipare il problema.

Un processo richiede una sequenza. La maggior parte delle attività sono sequenziali. Non ha senso confondere l'ordine.

Ma la cosa grandiosa della programmazione - che include gli script - è il testing. Test, test, test. Quali script di test hai attualmente per convalidare la correttezza dei tuoi script?

Il tuo capo sta cercando di guidarti dall'essere uno script per bambini a un programmatore. Questa è una buona direzione per entrare. Alle persone che vengono dopo di te piacerai.

MA. Ricorda sempre le tue radici orientate al processo. Se ha senso disporre delle funzioni ordinate nella sequenza in cui sono in genere eseguite, allora fallo almeno come primo passaggio.

Successivamente, vedrai che alcune delle tue funzioni gestiscono l'input, altre l'output, altre l'elaborazione, altre la modellazione dei dati e altre la manipolazione dei dati, quindi potrebbe essere intelligente raggruppare metodi simili, magari spostandoli in file separati .

Più tardi, potresti arrivare a capire che ora hai scritto librerie di piccole funzioni di supporto che usi in molti dei tuoi script.

Commenti e spaziatura non possono avvicinarsi in alcun modo alla leggibilità che le funzioni possono fare, come dimostrerò. Senza funzioni, non puoi vedere la foresta per gli alberi - grandi problemi si nascondono tra molte linee di dettaglio. In altre parole, le persone non possono contemporaneamente concentrarsi sui dettagli fini e sul quadro generale. Ciò potrebbe non essere ovvio in una breve sceneggiatura; fintanto che rimane breve può essere abbastanza leggibile. Il software diventa più grande, tuttavia, non più piccolo, e certamente fa parte dell'intero sistema software della tua azienda, che è sicuramente molto più grande, probabilmente milioni di linee.

Considera se ti ho dato istruzioni come questa:

Place your hands on your desk.
Tense your arm muscles.
Extend your knee and hip joints.
Relax your arms.
Move your arms backwards.
Move your left leg backwards.
Move your right leg backwards.
(continue for 10,000 more lines)

Prima di arrivare a metà, o addirittura del 5%, avresti dimenticato quali erano i primi passi. Non è possibile individuare la maggior parte dei problemi, perché non è possibile vedere la foresta per gli alberi. Confronta con le funzioni:

stand_up();
walk_to(break_room);
pour(coffee);
walk_to(office);

Questo è sicuramente molto più comprensibile, indipendentemente da quanti commenti potresti inserire nella versione sequenziale riga per riga. Inoltre rende molto più probabile che noterai che ti sei dimenticato di preparare il caffè, e probabilmente hai dimenticato sit_down () alla fine. Quando la tua mente sta pensando ai dettagli di grep e awk regexes, non puoi pensare a un quadro generale: "e se non ci fosse il caffè fatto?

Le funzioni consentono principalmente di vedere il quadro generale e notare che hai dimenticato di preparare il caffè (o che qualcuno potrebbe preferire il tè). In un altro momento, in un diverso stato d'animo, ti preoccupi per l'implementazione dettagliata.

Ci sono anche altri vantaggi discussi in altre risposte, ovviamente. Un altro vantaggio non chiaramente indicato nelle altre risposte è che le funzioni forniscono una garanzia importante per prevenire e correggere i bug. Se scopri che qualche variabile $ foo nella funzione corretta walk_to () era sbagliata, sai che devi solo guardare le altre 6 righe di quella funzione per trovare tutto ciò che potrebbe essere stato interessato da quel problema e tutto ciò che potrebbe hanno causato che fosse sbagliato. Senza funzioni (appropriate), qualsiasi cosa nell'intero sistema potrebbe essere causa di errori di $ foo e qualsiasi cosa potrebbe essere influenzata da $ foo. Pertanto non è possibile correggere $ foo in modo sicuro senza riesaminare ogni singola riga del programma. Se $ foo è locale in una funzione,

Alcuni truismi rilevanti sulla programmazione:

• Il tuo programma cambierà, anche se il tuo capo insiste che non è così.
• Solo il codice e l'input influiscono sul comportamento del programma.
• La denominazione è difficile.

I commenti iniziano come un gap-gap per non essere in grado di esprimere chiaramente le tue idee nel codice * e peggiorare (o semplicemente sbagliare) con il cambiamento. Pertanto, se possibile, esprimete concetti, strutture, ragionamento, semantica, flusso, gestione degli errori e qualsiasi altra cosa pertinente alla comprensione del codice come codice.

Detto questo, le funzioni di Bash hanno alcuni problemi che non si trovano nella maggior parte delle lingue:

• Il namespace è terribile in Bash. Ad esempio, dimenticare di utilizzare la localparola chiave provoca l'inquinamento dello spazio dei nomi globale.
• L'uso di local foo="$(bar)"risultati comporta la perdita del codice di uscita dibar .
• Non ci sono parametri nominati, quindi devi tenere presente cosa "$@"significa in contesti diversi.

* Mi dispiace se questo offende, ma dopo aver usato i commenti per alcuni anni e aver sviluppato senza di loro ** per altri anni è abbastanza chiaro quale è superiore.

** È ancora necessario utilizzare i commenti per le licenze, la documentazione API e simili.

Il tempo è denaro

Ci sono altre buone risposte che fanno luce sui motivi tecnici per scrivere in modo modulare una sceneggiatura, potenzialmente lunga, sviluppata in un ambiente di lavoro, sviluppata per essere utilizzata da un gruppo di persone e non solo per uso personale.

Voglio concentrarmi su un aspetto: in un ambiente di lavoro "il tempo è denaro" . Quindi l'assenza di bug e le prestazioni del tuo codice vengono valutate insieme a leggibilità , testabilità, manutenibilità , rifattabilità, riusabilità ...

Scrivendo in "moduli" un codice diminuirà il tempo di lettura necessaria non solo dal coder in sé, ma anche il tempo impiegato dai tester o dal boss. Inoltre, nota che il tempo di un capo viene generalmente pagato più del tempo di un programmatore e che il tuo capo valuterà la qualità del tuo lavoro.

Inoltre scrivere in "moduli" indipendenti un codice (anche uno script bash) ti consentirà di lavorare in "parallelo" con altri componenti del tuo team abbreviando i tempi complessivi di produzione e usando al meglio l'esperienza del singolo, per rivedere o riscrivere una parte con nessun effetto collaterale sugli altri, per riciclare il codice che hai appena scritto "così com'è"per un altro programma / script, per creare librerie (o librerie di snippet), per ridurre le dimensioni complessive e la relativa probabilità di errori, eseguire il debug e testare accuratamente ogni singola parte ... e ovviamente organizzerà nella sezione logica il tuo programma / script e migliorarne la leggibilità. Tutto ciò che farà risparmiare tempo e denaro. Lo svantaggio è che devi attenersi agli standard e commentare le tue funzioni (che devi comunque fare in un ambiente di lavoro).

Aderire a uno standard rallenterà il tuo lavoro all'inizio, ma accelererà il lavoro di tutti gli altri (e anche dei tuoi) in seguito. In effetti, quando la collaborazione cresce nel numero di persone coinvolte, questo diventa un bisogno inevitabile. Quindi, per esempio, anche se credo che le variabili globali debbano essere definite a livello globale e non in una funzione, posso capire uno standard che le inizializza in una funzione declare_variables()chiamata sempre chiamata nella prima riga di main()quella ...

Ultimo ma non meno importante, non sottovalutare la possibilità nei moderni editor di codice sorgente di mostrare o nascondere routine selettivamente separate ( piegatura del codice ). Ciò manterrà compatto il codice e focalizzato l'utente risparmiando ancora tempo.

^{Qui sopra puoi vedere come si svolge solo la walk_into_bar()funzione. Anche degli altri erano lunghi 1000 righe ciascuno, si poteva comunque tenere sotto controllo tutto il codice in una singola pagina. Nota che è piegata anche la sezione in cui vai a dichiarare / inizializzare le variabili.}

A parte le ragioni fornite in altre risposte:

9. Psicologia: un programmatore la cui produttività viene misurata in righe di codice avrà un incentivo a scrivere codice inutilmente dettagliato. Più la gestione si concentra su linee di codice, maggiore è l'incentivo che il programmatore deve espandere il proprio codice con complessità non necessaria. Ciò è indesiderabile poiché una maggiore complessità può comportare un aumento dei costi di manutenzione e un maggiore sforzo richiesto per la correzione degli errori.
   • WP, righe di codice sorgente; Svantaggi, # 9

Un altro motivo che viene spesso trascurato è l'analisi della sintassi di bash:

set -eu

echo "this shouldn't run"
{
echo "this shouldn't run either"

Questo script ovviamente contiene un errore di sintassi e bash non dovrebbe eseguirlo affatto, giusto? Sbagliato.

~ $ bash t1.sh
this shouldn't run
t1.sh: line 7: syntax error: unexpected end of file

Se avessimo racchiuso il codice in una funzione, ciò non accadrebbe:

set -eu

main() {
  echo "this shouldn't run"
  {
  echo "this shouldn't run either"
}

main

~ $ bash t1.sh
t1.sh: line 10: syntax error: unexpected end of file