Hvorfor skrive et helt bash-script i funktioner?

Jeg er begyndt at bruge det samme stil med bash-programmering efter læsning af Kfir Lavis blogindlæg “Defensive Bash Programming” . Han giver en hel del gode grunde, men personligt finder jeg disse de vigtigste:

• procedurer bliver beskrivende: det er meget lettere at finde ud af, hvad en bestemt del af koden antages at gøre. I stedet for kodevæg ser du “Åh, find_log_errors -funktionen læser den logfil for fejl”. Sammenlign den med at finde en hel masse awk / grep / sed-linjer, der brug gud ved hvilken type regex midt i et langt script – du har ingen idé om, hvad det gør der, medmindre der er kommentarer.

• du kan fejle funktioner ved at omslutte i set -x og set +x. Når du ved, at resten af koden fungerer okay, kan du bruge dette trick til kun at fokusere på fejlfinding af den specifikke funktion. Sikker på, du kan vedlægge dele af scriptet, men hvad nu hvis det er en lang del? Det er lettere at gøre noget som dette:

   set -x parse_process_list set +x 

• udskrivningsbrug med cat <<- EOF . . . EOF. Jeg har brugt den et par gange for at gøre min kode meget mere professionel. Derudover er parse_args() med getopts -funktionen ret praktisk. Igen hjælper dette med læsbarheden i stedet for at skubbe alt ind i scriptet som en kæmpe tekstmur. Det er også praktisk at genbruge disse.

Og selvfølgelig er dette meget mere læsbar for nogen, der kender C eller Java eller Vala, men har begrænset bash-oplevelse. Hvad effektivitet angår, er der ikke meget af, hvad du kan gøre – bash i sig selv er ikke det mest effektive sprog, og folk foretrækker perl og python, når det kommer til hastighed og effektivitet.Du kan dog nice en funktion:

nice -10 resource_hungry_function 

Sammenlignet med at kalde pænt på hver eneste kode kode, dette mindsker en hel masse skrivning OG kan nemt bruges, når du kun vil have en del af dit script til at køre med lavere prioritet.

At køre funktioner i baggrunden hjælper efter min mening også, når du vil have hele flok udsagn, der skal køres i baggrunden.

Nogle af eksemplerne, hvor jeg har brugt denne stil:

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

Kommentarer

• Jeg er ikke sikker på, at du skal tage forslag fra denne artikel meget seriøst. Indrømmet, det har et par gode ideer, men det er tydeligvis ikke nogen, der plejede at shell scripting. Ikke en enkelt variabel i et hvilket som helst af eksemplerne er citeret (!) og det foreslås at bruge UPPER C ASE-variabelnavne, hvilket ofte er en meget dårlig idé, da de kan komme i konflikt med eksisterende miljøer. Dine punkter i dette svar giver mening, men den linkede artikel ser ud til at være skrevet af en person, der lige er vant til andre sprog og forsøger at tvinge deres stil til bash.
• @terdon Jeg gik tilbage til artiklen og læste den igen. Det eneste sted, hvor forfatteren nævner navngivning af store bogstaver, er i ” Uforanderlige globale variabler “. Hvis du betragter globale variabler som dem, der skal være inden for funktion ‘ s miljø, er det fornuftigt at gøre dem kapital. På sideanmærkning bash ‘ s manual ‘ t tilstandskonvention for variabel sag. Selv her accepteret svar siger ” normalt ” og den eneste ” standard ” er af Google, som ikke ‘ t repræsenterer hele it-branchen.
• @terdon på en anden note, jeg er 100% enig i, at variabel citering burde have været nævnt i artiklen, og det er også blevet påpeget i kommentarerne på bloggen. Jeg vil heller ikke ‘ ikke bedømme nogen, der bruger denne kodningsform, uanset om de ‘ bruges til et andet sprog. Hele dette spørgsmål og svar viser tydeligt, at der er ‘ fordele ved det, og personens ‘ s-grad, som de ‘ bruges til et andet sprog er sandsynligvis irrelevant her.
• @terdon godt, artiklen blev sendt som en del af ” kilden ” materiale. Jeg kunne have sendt alt som mine egne meninger, men jeg var bare nødt til at give æren for, at nogle af de ting, jeg lærte fra artiklen, og at alt dette kom fra research over tid. Forfatterens ‘ s linkede side viser, at de har god erfaring med Linux og IT generelt, så jeg ‘ gætter på, at artiklen ikke ‘ Det viser jeg virkelig ikke, men jeg stoler på din oplevelse, når det kommer til Linux og shell-scripting, så du har måske ret.
• At ‘ er et fremragende svar, men jeg ‘ d vil også gerne tilføje, at variabelt omfang i Bash er funky. Af den grund foretrækker jeg at erklære mine variabler i funktioner ved hjælp af local og kalde alt via main() -funktionen. Dette gør tingene meget mere håndterbare, og du kan undgå en potentielt rodet situation.

Læsbarhed er en ting. Men der er mere ved modularisering end bare dette. ( Semi-modularisering er måske mere korrekt for funktioner.)

I funktioner kan du holde nogle variabler lokale, hvilket øger pålidelighed og mindsker risikoen for ting bliver rodet.

En anden fordel ved funktioner er genanvendelighed . Når en funktion er kodet, kan den anvendes flere gange i scriptet. Du kan også porte det til et andet script.

Din kode kan nu være lineær, men i fremtiden kan du komme ind i området multi-threading eller multi- behandling i Bash-verdenen. Når du lærer at gøre ting i funktioner, vil du være godt rustet til at gå ind i parallel.

Et punkt mere at tilføje. Som Etsitpab Nioliv bemærker i kommentaren nedenfor, er det let at omdirigere fra funktioner som en sammenhængende enhed. Men der er endnu et aspekt af omdirigeringer med funktioner. Omdirigeringerne kan nemlig indstilles langs funktionsdefinitionen. F.eks .:

f () { echo something; } > log 

Nu er der ikke behov for nogen eksplicit omdirigering af funktionsopkaldene.

$ f 

Dette kan spare mange gentagelser, hvilket igen øger pålideligheden og hjælper med at holde tingene i orden.

Se også

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

Kommentarer

• Meget god svar, selvom det ville være meget bedre, hvis det blev opdelt i funktioner.
• Måske tilføje, at funktionerne giver dig mulighed for at importere dette script til et andet script (ved hjælp af source eller . scriptname.sh, og brug disse funktioner som om de var i dit nye script.
• At ‘ allerede er dækket i et andet svar.
• Det sætter jeg pris på. Men jeg ‘ ville hellere lade andre mennesker også være vigtige.
• Jeg stod over for en sag i dag, hvor jeg måtte omdirigere noget af output fra et script til en fil (for at sende det via e-mail) i stedet for at ekko. Jeg var simpelthen nødt til at udføre myFunction > > myFile for at omdirigere output for de ønskede funktioner. Ret praktisk. Kan være relevant.

I min kommentar nævnte jeg tre fordele ved funktioner:

1. De er lettere at teste og kontrollere rigtigheden.

2. Funktioner kan let genbruges (hentes) i fremtidige scripts

3. Din chef kan lide dem.

Og undervurder aldrig vigtigheden af nummer 3.

Jeg vil gerne tage endnu et spørgsmål op:

… så at være i stand til vilkårligt at bytte kørselsrækkefølgen er ikke noget, vi generelt ville gøre. For eksempel vil du ikke pludselig ønske at lægge declare_variables efter walk_into_bar, der ville knække ting.

For at få fordelen ved at bryde kode i funktioner, bør man prøve at gøre funktionerne så uafhængige som muligt. Hvis walk_into_bar kræver en variabel, der bruges ikke andetsteds, så skal variablen defineres i og gøres lokal til walk_into_bar. Processen med at adskille koden i funktioner og minimere deres indbyrdes afhængigheder bør gøre koden klarere og enklere .

Ideelt set skal funktioner være lette at teste individuelt. Hvis de på grund af interaktioner ikke er lette at teste, er det et tegn på, at de kan have gavn af refactoring.

Kommentarer

• I ‘ d hævder, at det ‘ undertiden er fornuftigt at modellere og håndhæve disse afhængigheder i forhold til refactoring for at undgå dem (for hvis der er enoug h af dem, og de ‘ er tilstrækkeligt behårede, det kan bare føre til et tilfælde, hvor ting slet ikke er moduleret til funktioner). En meget kompliceret brugssag inspirerede engang en ramme til netop det .
• Hvad der skal opdeles i funktioner skal være, men eksemplet tager det for langt. Jeg tror, at den eneste der virkelig bugserer mig er variabeldeklarationsfunktionen. Globale variabler, især statiske, bør defineres globalt i et kommenteret afsnit dedikeret til dette formål. Dynamiske variabler skal være lokale for de funktioner, der bruger og ændrer dem.
• @Xalorous I ‘ har set en praksis, hvor globale variabler initialiseres i en procedure, som et mellemliggende og hurtigt trin inden udviklingen af en procedure, der læser deres værdi fra en ekstern fil … Jeg er enig i, at det skal være renere at adskille definition og initialisering, men sjældent skal du bøje for at gennemgå til fordel nummer 3 ;-)

Mens jeg er helt enig med genanvendelighed , læsbarhed og delikat kysse bosserne, men der er en anden fordel ved funktioner i bash : variabelt omfang . Som LDP viser :

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

Jeg kan ikke se dette meget ofte i den virkelige verden shell-scripts, men det ser ud som en god idé til mere komplekse scripts. At reducere samhørighed hjælper med at undgå bugs, hvor du klemmer en variabel, der forventes i en anden del af koden .

Genanvendelighed betyder ofte at oprette et fælles funktionsbibliotek og source at indføre dette bibliotek i alle dine scripts. Dette hjælper dem ikke med at løbe hurtigere, men det hjælper dig med at skrive dem hurtigere.

Kommentarer

• Få mennesker bruger udtrykkeligt local, men jeg tror, de fleste, der skriver scripts opdelt i funktioner, følger stadig designprincippet. Usign local gør det bare sværere at introducere bugs.
• local gør variabler tilgængelige for at fungere og dets børn, så det ‘ er virkelig rart at have en variabel, der kan sendes ned fra funktion A, men ikke tilgængelig for funktion B, som muligvis vil have en variabel med samme navn, men med et andet formål.Så ‘ er godt til at definere omfanget, og som Voo sagde – mindre bugs

Du opdeler koden i funktioner af samme grund som du ville gøre for C / C ++, python, perl, ruby eller hvilken som helst programmeringssprogkode. Den dybere årsag er abstraktion – du indkapsler opgaver på lavere niveau i primitiver (funktioner) på højere niveau, så du ikke behøver at bekymre dig om, hvordan tingene gøres. Samtidig bliver koden mere læsbar (og vedligeholdelig), og programlogik bliver mere tydelig.

Men når jeg ser på din kode, finder jeg det ret underligt at have en funktion til at erklære variabler; dette får mig virkelig til at hæve et øjenbryn.

Kommentarer

• Undervurderet svar IMHO. Foreslår du at deklarere variablerne i main funktion / metode, så?

En helt anden grund end dem, der allerede er givet i andre svar: en af grundene til, at denne teknik undertiden bruges, hvor den eneste ikke-funktion-definition-sætning på øverste niveau er et kald til main, er at sikre, at scriptet ikke ved et uheld gør noget grimt, hvis scriptet er afkortet. Scriptet kan blive afkortet hvis det er ledes fra proces A til proces B (shell), og proces A afsluttes uanset årsag, før den er færdig med at skrive hele scriptet. Dette er især sandsynligt, at hvis proces A henter scriptet fra en ekstern ressource. Mens det af sikkerhedsmæssige årsager ikke er en god idé, er det noget, der gøres, og nogle scripts er blevet ændret for at foregribe problemet.

Kommentarer

• Interessant! Men jeg finder det foruroligende, at man skal tage sig af disse ting i hvert af programmerne. På den anden side er nøjagtigt dette main() mønster normalt i Python, hvor man bruger if __name__ == '__main__': main() i slutningen af filen.
• Python-idiomet har fordelen ved at lade andre scripts import det aktuelle script uden at køre main. Jeg formoder, at en lignende vagt kunne sættes i et bash-script.
• @Jake Cobb Ja. Det gør jeg nu i alle nye bash-scripts. Jeg har et script, der indeholder en kerneinfrastruktur af funktioner, der bruges af alle nye scripts. Dette script kan hentes eller udføres. Hvis den hentes, udføres dens hovedfunktion ikke. Registrering af kilde vs udførelse sker via det faktum, at BASH_SOURCE indeholder navnet på det udførende script. Hvis det ‘ er det samme som kerneskriptet, udføres scriptet. Ellers indkøbes ‘.
• Nært relateret til dette svar bruger bash simpel linebaseret behandling, når den kører fra en fil, der allerede er på disken. Hvis filen ændres, mens scriptet kører, ændres linjetælleren ikke ‘ t, og den ‘ fortsætter på den forkerte linje. Indkapsling af alt i funktioner sikrer, at det ‘ er indlæst i hukommelsen, før det kører noget, så ændring af filen påvirker ikke ‘ det.

Nogle relevante truisms om programmering:

• Dit program ændres, selvom din chef insisterer på, at dette ikke er tilfældet.
• Kun kode og input påvirker programmets opførsel.
• At navngive er svært.

Kommentarer starter som et stop-gap for ikke at være i stand til at udtrykke dine ideer tydeligt i kode * og blive værre (eller simpelthen forkert) med ændringer. Derfor, hvis det overhovedet er muligt, udtryk begreber, strukturer, ræsonnement, semantik, flow, fejlhåndtering og alt andet, der er relevant for forståelsen af koden som kode.

Når det er sagt, Bash-funktioner har nogle problemer, der ikke findes på de fleste sprog:

• Navneafstand er forfærdeligt i Bash. Hvis man for eksempel glemmer at bruge local nøgleordet, forurenes det globale navneområde.
• Brug af local foo="$(bar)" resulterer i mister udgangskoden til bar .
• Der er ingen navngivne parametre, så du skal huske på, hvad "$@" betyder i forskellige sammenhænge.

* Jeg beklager, hvis dette fornærmer, men efter ved hjælp af kommentarer i nogle år og udvikling uden dem ** i flere år er det ret klart, hvad der er overlegen.

** Brug af kommentarer til licensering, API-dokumentation og lignende er stadig nødvendig.

Kommentarer

• Jeg indstillede næsten alle lokale variabler ved at erklære dem nul i starten af funktionen …local foo="" Indstil dem derefter ved hjælp af kommandokørsel til at handle på resultatet … foo="$(bar)" || { echo "bar() failed"; return 1; }. Dette får os hurtigt ud af funktionen, når en krævet værdi ikke kan indstilles. De krøllede seler er nødvendige for at sikre, at return 1 kun udføres ved fiasko.
• Ville bare kommentere dine punkter. Hvis du bruger ‘ subshell-funktioner ‘ (funktioner afgrænset af parentes og ikke krøllede parenteser), donerer du 1) ‘ behøver ikke at bruge lokalt, men få fordelene ved lokalt, 2) Don ‘ t løb ind i problemet med at miste udgangskoden til kommandosubstitution i local foo=$(bar) så meget (fordi du ‘ ikke bruger lokalt) 3) Don ‘ behøver ikke at bekymre dig om utilsigtet forurening eller ændring af globalt omfang 4) er i stand til at videregive ‘ navngivne parametre ‘ der er ‘ lokal ‘ til din funktion ved hjælp af syntaksen foo=bar baz=buz my-command

En proces kræver en sekvens. De fleste opgaver er sekventielle. Det giver ingen mening at rode med ordren.

Men den super store ting ved programmering – som inkluderer scripting – er testning. Test, test, test. Hvilke testskripter har du i øjeblikket for at validere rigtigheden af dine scripts?

Din chef prøver at guide dig fra at være et kiddy script til at være programmør. Dette er en god retning at gå i. Folk, der følger dig, vil kunne lide dig.

MEN. Husk altid dine procesorienterede rødder. Hvis det giver mening at få funktionerne ordnet i den rækkefølge, som de typisk udføres i, skal du gøre det, i det mindste som et første pass.

Senere vil du komme til at se, at nogle af dine funktioner er håndtering af input, andre output, andre behandler, andre modellerer data, og andre manipulerer dataene, så det kan være smart at gruppere lignende metoder, måske endda flytte dem til separate filer.

Senere stadig kan du muligvis kom til at indse, at du nu har skrevet biblioteker med små hjælperfunktioner, som du bruger i mange af dine scripts.

Kommentarer og afstand kan ikke komme nogen steder nær læsbarheden, som funktioner kan, som jeg vil demonstrere. Uden funktioner kan du ikke se skoven for træerne – store problemer skjuler sig i mange detaljeringslinjer. Med andre ord kan folk ikke samtidig fokusere på de fine detaljer og på det store billede. Det er måske ikke indlysende i et kort script; så længe det forbliver kort, kan det være læsbart nok. Software bliver dog større, dog ikke mindre og bestemt er det en del af hele virksomhedens softwaresystem, som helt sikkert er meget større, sandsynligvis millioner af linjer.

Overvej, om jeg gav dig instruktioner som denne:

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) 

Da du kom halvvejs igennem eller endda 5% igennem, ville du have glemt, hvad de første trin var. Du kunne muligvis ikke se de fleste problemer, fordi du ikke kunne se skoven for træerne. Sammenlign med funktioner:

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

Det er bestemt meget mere forståeligt, uanset hvor mange kommentarer du kan placere i rækkefølgen efter hinanden. gør det også langt mere sandsynligt, at du “vil bemærke, at du har glemt at laver kaffen, og glemte sandsynligvis sit_down () i slutningen. Når dit sind tænker på detaljerne i grep og awk regexes, kan du ikke tænke stort billede – “hvad hvis der ikke er lavet kaffe”?

Funktioner giver dig primært mulighed for at se det store billede, og bemærk, at du har glemt at lave kaffen (eller at nogen måske foretrækker te). På et andet tidspunkt, i en anden tankegang, bekymrer du dig om den detaljerede implementering.

Der er også andre fordele, der diskuteres i Andre svar, selvfølgelig. En anden fordel, der ikke er tydeligt angivet i de andre svar, er, at funktioner giver en garanti, der er vigtig for at forhindre og rette bugs. Hvis du opdager, at en eller anden variabel $ foo i den korrekte funktion walk_to () var forkert, ved du, at du kun skal se på de andre 6 linjer i den funktion for at finde alt, hvad der kunne have været påvirket af dette problem, og alt, hvad der kunne har fået det til at være forkert. Uden (ordentlige) funktioner kan alt og alt i hele systemet være en årsag til, at $ foo er forkert, og alt og alt kan blive påvirket af $ foo. Derfor kan du ikke sikkert rette $ foo uden at undersøge hver eneste linje i programmet igen. Hvis $ foo er lokal for en funktion, kan du garantere, at ændringer er sikre og korrekte ved kun at kontrollere den funktion.

Kommentarer

• Dette er ikke ‘ t bash syntaksen.Det ‘ er dog en skam; Jeg tror ikke ‘, at der er en måde at videregive input til sådanne funktioner. (dvs. pour(); < coffee). Det ligner mere c++ eller php (tror jeg).
• @ tjt263 uden parentes, det ‘ s bash-syntaks: hæld kaffe. Med parens er det ‘ stort set alle andre sprog. 🙂

Tid er penge

Der er andre gode svar , der spreder lys over de tekniske grunde til at skrive modulært et script, potentielt lang, udviklet i et arbejdsmiljø, udviklet til at blive brugt af en gruppe personer og ikke kun til eget brug.

Jeg vil fokus på en forventer: i et arbejdsmiljø “tid er penge” . Så fraværet af bugs og ydeevnen af din kode evalueres sammen med læsbarhed , testbarhed, vedligeholdelsesevne, refactorability, genanvendelighed …

Skrivning i ” moduler “ en kode reducerer læsningstiden ikke kun af koderen selv, men endda den tid, der bruges af testere eller af chefen. Desuden skal du bemærke, at tiden for en chef normalt betales mere end tiden for en kode, og at din chef vil evaluere kvaliteten af dit job.

Desuden skriver du i uafhængige “moduler” en kode (endda et bash-script) giver dig mulighed for at arbejde i “parallel” med anden komponent i dit team, der forkorter den samlede produktionstid og i bedste fald bruger ekspertisen til at gennemgå eller omskrive en del uden bivirkninger på de andre, til at genbruge den kode, du lige har skrevet “som den er” for et andet program / script, for at oprette biblioteker (eller biblioteker med uddrag), for at reducere den samlede størrelse og den relaterede sandsynlighed for fejl, for at debugge og teste grundigt hver enkelt del … og selvfølgelig vil det organisere sig logisk sektion dit program / script og forbedre dets læsbarhed. Alt, hvad der sparer tid og så penge. Ulempen er, at du skal holde dig til standarder og kommentere dine funktioner (som du ikke har eless at gøre i et arbejdsmiljø).

At overholde en standard bremser dit arbejde i starten, men det vil fremskynde alle andres arbejde (og også din) bagefter. Når samarbejdet vokser i antal involverede mennesker, bliver dette faktisk et uundgåeligt behov. Så for eksempel, selvom jeg mener, at de globale variabler skal defineres globalt og ikke i en funktion, kan jeg forstå en standard, der inizialiserer dem i en funktion, der hedder declare_variables() kaldes altid i den første linje i main() en …

Sidst men ikke mindst, undervurder ikke muligheden i moderne kildekode redaktører til at vise eller skjule selektivt separate rutiner ( Kodefoldning ). Dette vil holde koden kompakt og fokusere brugeren igen til at spare tid.

^{Her over kan du se, hvordan det udfoldes kun walk_into_bar() -funktionen. Selv de andre var 1000 linjer lange hver, du kunne stadig holde styr på al koden på en enkelt side. Bemærk, at det er foldet, selv det afsnit, hvor du går til at erklære / initialisere variablerne.}

En anden grund der ofte overses, er bash “s syntax parsing:

set -eu echo "this shouldn"t run" { echo "this shouldn"t run either" 

Dette script indeholder tydeligvis en syntaksfejl, og bash burde slet ikke køre det, ikke? Forkert.

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

Hvis vi indpakkede koden i en funktion, ville dette ikke ske:

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 

Bortset fra årsagerne i andre svar:

9. Psykologi: En programmør, hvis produktivitet måles i linier med kode, vil have et incitament til at skrive unødigt omfattende kode. Jo mere ledelse er med fokus på kodelinjer, jo mere incitament har programmøren til at udvide sin kode med unødvendig kompleksitet. Dette er uønsket, da øget kompleksitet kan føre til øgede omkostninger til vedligeholdelse og øget indsats, der kræves til fejlrettelse.
   • WP, kildelinjer for kode; Ulemper, nr. 9

Kommentarer

• Det er ikke så dårligt svar, som nedstemningerne siger. Bemærk: agc siger, også dette er en mulighed, og ja, det er det. Han siger ikke ‘, at det ville være den eneste mulighed, og ikke ‘ t beskylder nogen, siger kun fakta. Selvom jeg synes i dag næsten er uhørt, er en direkte ” kodelinje ” – > ” $$ ” stil kontraktjob, på indirekte betyder det, at det er ret almindeligt, at ja, massen af den producerede kode tæller af lederne / bosser.