Scrivere buoni script è difficile. C'è l'ovvia abilità PEBKAC, ovviamente, ma anche la magia e la storia antiche, con le convenzioni legacy che vanno a Plan 9 e FLOW-MATIC, che la maggior parte delle persone non capisce o di cui non si preoccupa davvero quando scrive il proprio software. Quindi, la mancanza di un crimine e punizione dostoevskiano nello sviluppo del software significa anche che i codici possono essere pigri e scrivere come vogliono.
Un sacco di lune fa, mi sono imbattuto in un piccolo programma pulito progettato per rendere meno schifoso il tuo script di shell. Si chiama ShellCheck, è disponibile come console online e puoi anche installarlo praticamente in qualsiasi distribuzione e quindi integrarlo nei tuoi flussi di lavoro o altro. Incuriosito, sono andato a-esplorare.
Fuoco nel buco
Ho iniziato con il mio script di shell:simWANsim, un programma progettato per simulare la latenza della rete WAN in un modo semplice e conveniente (non c'è bisogno di interfacce multiple, live media o simili). Questo è essenzialmente uno script BASH e volevo vedere quanto fosse efficiente ed elegante. A proposito, lo script non ha bisogno di essere eseguibile per essere valutato.
shellcheck "nome script"
Sono rimasto sorpreso dalla quantità di errori e avvisi, ma poi, quando ho iniziato a leggere, molti di questi erano in realtà più istanze dello stesso tipo di cattiva pratica di codifica, ripetuta più volte attraverso lo script. Inoltre, mi sono reso conto che gli errori avevano un senso, erano scritti in modo chiaro e non erano solo technobabble casuali. Suggerimenti pratici e utili - con esempi - su come correggere i tuoi script.
Uno degli errori più comuni era l'uso dei backtick invece della notazione $(). Avevo anche molte altre righe nella stessa vena, l'uso di let expr, la mancanza di virgolette doppie per prevenire il globbing e la divisione delle parole e alcuni altri problemi minori come quello.
In simWANsim.sh riga 152:
EGREP=`which egrep`
^-----------^ SC2006:usa la notazione $(...) invece di legacy backticked `. ..`.
^---^ SC2230:che non è standard. Usa invece il 'comando -v' integrato.
Intendevi:
EGREP=$(che egrep)
In simWANsim.sh riga 304:
let PRNT=$PRNT+1
^--------------^ SC2219:Invece di 'let expr', preferire (( espr )) .
Sono rimasto colpito dal caso di studio [sic]. Ciao ciao. Avevo usato opzioni che non avevo realmente gestito e inoltre non avevo un caso generico per flag non specificati. Sembra un piccolo suggerimento intelligente. Più astuto.
In simWANsim.sh riga 178:
case $flag in
^-- SC2213:getopts specificato -a, ma non è gestito da questo 'case'.
^-- SC2213:getopts specificato -s, ma non è gestito da questo 'caso'.
^-- SC2220:i flag non validi non vengono gestiti. Aggiungi un *) caso.
Nessuno di questi è cardinale, ma allora perché no. Dopotutto, se riesci a rendere il tuo codice il più pulito ed elegante possibile, elimini la possibilità di errori di case d'angolo e comportamenti strani. Non mi piace scrivere codice, ma se lo stai facendo, potresti anche farlo bene.
Ho anche testato uno script molto generico per vedere cosa succede quando non ci sono errori. Lo strumento della riga di comando esce, senza alcun output. Se utilizzi lo strumento online, riceverai un messaggio stampato che recita:
$ shellcheck myscript
Nessun problema rilevato!
Infine, puoi abbellire il tuo output, modificare la verbosità dell'output, formattare lo stile e i colori, forzare ShellCheck a lavorare con un dialetto specifico di shell (inclusi sh, bash, dash e ksh), mostrare collegamenti wiki, che possono essere utili per chi cerca per ulteriori informazioni e risorse sulle pratiche di codifica e sugli errori, oltre ad alcune altre opzioni. Tutto sommato, è semplice, efficace ed elegante.
Conclusione
ShellCheck è un'utilità davvero interessante. Normalmente non mi preoccupo molto per cose di questo tipo, ma posso apprezzare la bellezza quando ce n'è una da trovare. Lo strumento stesso è stato scritto in Haskell, il che ci pone tutti su un piano metafisico completamente diverso, ma non lo terremo contro l'autore.
Se ti capita di utilizzare script di shell nel tuo ambiente, potresti prendere in considerazione la possibilità di provare ShellCheck. Penso che rimarrai sorpreso, perché dovrebbero esserci tonnellate di piccoli errori legacy nel tuo codice, poiché le persone raramente tornano indietro e aggiustano le vecchie cose e finisci con gli avanzi che non hanno più senso o servono a nessuno scopo. Nell'era del rigonfiamento inutile, l'essere frugali ed eleganti conta. Questo è un modo intelligente per iniziare la tua dieta a guscio. E così finisce un altro articolo.