Hvorfor skrive et helt bash-skript i funksjoner?

Jeg har begynt å bruke det samme stil med bash-programmering etter å ha lest Kfir Lavis blogginnlegg «Defensive Bash Programming» . Han gir ganske mange gode grunner, men personlig synes jeg disse er de viktigste:

• prosedyrer blir beskrivende: det er mye lettere å finne ut hva en bestemt del av koden antas å gjøre. I stedet for vegg av kode ser du «Å, find_log_errors -funksjonen leser loggfilen for feil.» Sammenlign den med å finne mange awk / grep / sed-linjer som bruk gud vet hvilken type regex midt i et langt skript – du har ingen anelse om hva det gjør der med mindre det er kommentarer.

• du kan feilsøke funksjoner ved å legge inn i set -x og set +x. Når du vet at resten av koden fungerer bra, kan du bruke dette trikset til å fokusere på feilsøking bare av den spesifikke funksjonen. Jo, du kan legge ved deler av skriptet, men hva om det er en lang del? Det er lettere å gjøre noe slikt:

   set -x parse_process_list set +x 

• utskriftsbruk med cat <<- EOF . . . EOF. Jeg har brukt den ganske mange ganger for å gjøre koden min mye mer profesjonell. I tillegg er parse_args() med getopts -funksjonen ganske praktisk. Igjen, dette hjelper med lesbarhet, i stedet for å skyve alt inn i skriptet som en gigantisk tekstvegg. Det er også praktisk å gjenbruke disse.

Og selvfølgelig er dette mye mer lesbar for noen som kan C eller Java, eller Vala, men har begrenset bash-erfaring. Så langt som effektivitet går, er det ikke mye av det du kan gjøre – bash i seg selv er ikke det mest effektive språket, og folk foretrekker perl og python når det gjelder hastighet og effektivitet.Du kan imidlertid nice en funksjon:

nice -10 resource_hungry_function 

Sammenlignet med å ringe fint på hver eneste linje med kode, dette reduserer mye skriving OG kan enkelt brukes når du bare vil at en del av skriptet skal kjøre med lavere prioritet.

Kjører funksjoner i bakgrunnen, hjelper etter min mening også når du vil ha hele haug med utsagn som skal kjøres i bakgrunnen.

Noen av eksemplene der jeg har brukt denne stilen:

• 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 bør ta noen forslag fra den artikkelen veldig seriøst. Gitt, den har noen få gode ideer, men det er tydeligvis ikke noen som pleide å shell scripting. Ikke en enkelt variabel i et hvilket som helst av eksemplene er sitert (!) og det foreslås å bruke OPPER C ASE-variabelnavn, som ofte er en veldig dårlig ide, siden de kan komme i konflikt med eksisterende miljøer. Dine poeng i dette svaret gir mening, men den lenkede artikkelen ser ut til å være skrevet av noen som bare er vant til andre språk og prøver å tvinge stilen deres til bash.
• @terdon Jeg gikk tilbake til artikkelen og leste den på nytt. Det eneste stedet der forfatter nevner store navn på variabelnavn er i » Uforanderlige globale variabler «. Hvis du anser globale variabler som de som må være innenfor funksjon ‘ s miljø, er det fornuftig å gjøre dem til kapital. På sidemerket bash ‘ s manual ‘ t tilstandskonvensjon for variabel sak. Selv her akseptert svar sier » vanligvis » og den eneste » standard » er av Google, som ikke ‘ t representerer hele IT-bransjen.
• @terdon på et annet notat, jeg er 100% enig i at variabel sitering burde vært nevnt i artikkelen, og det er blitt påpekt i kommentarene på bloggen også. Jeg vil heller ikke ‘ ikke bedømme noen som bruker denne kodestilen, uansett om de ‘ er vant til et annet språk. Hele dette spørsmålet og svarene viser tydelig ‘ fordelene med det, og personens ‘ s grad som de ‘ som brukes til et annet språk er sannsynligvis ikke relevant her.
• @terdon vel, artikkelen ble lagt ut som en del av » kilden » materiale. Jeg kunne ha postet alt som mine egne meninger, men jeg måtte bare gi æren for at noe av det jeg lærte fra artikkelen, og at alt dette kom fra å forske over tid. Forfatteren ‘ s linkedin-side viser at de har god erfaring med Linux og IT generelt, så jeg ‘ antar at artikkelen ikke ‘ t viser det virkelig, men jeg stoler på din erfaring når det gjelder Linux og shell-skripting, så du kan ha rett.
• At ‘ er et utmerket svar, men jeg ‘ vil også legge til at variabelt omfang i Bash er funky. Av den grunn foretrekker jeg å erklære variablene mine i funksjoner ved hjelp av local og ringe alt via main() -funksjonen. Dette gjør ting mye mer håndterlig, og du kan unngå en potensielt rotete situasjon.

Lesbarhet er en ting. Men det er mer ved modularisering enn bare dette. ( Semi-modularisering er kanskje mer riktig for funksjoner.)

I funksjoner kan du holde noen variabler lokale, noe som øker pålitelighet og reduserer sjansen for ting blir rotet opp.

En annen fordel med funksjoner er gjenbrukbarhet . Når en funksjon er kodet, kan den brukes flere ganger i skriptet. Du kan også portere den til et annet skript.

Koden din kan nå være lineær, men i fremtiden kan du gå inn i området multi-threading eller multi- behandling i Bash-verdenen. Når du lærer deg å gjøre ting i funksjoner, vil du være godt rustet for å gå inn i parallellen.

Et poeng til å legge til. Som Etsitpab Nioliv merker seg i kommentaren nedenfor, er det lett å omdirigere fra funksjoner som en sammenhengende enhet. Men det er ett aspekt til omdirigeringer med funksjoner. Omdirigeringene kan nemlig settes langs funksjonsdefinisjonen. F.eks .:

f () { echo something; } > log 

Nå er det ikke behov for eksplisitte omdirigeringer av funksjonsanropene.

$ f 

Dette kan spare mange repetisjoner, noe som igjen øker påliteligheten og hjelper med å holde orden på ting.

Se også

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

Kommentarer

• Veldig bra svar selv om det ville være mye bedre hvis det ble delt inn i funksjoner.
• Kanskje legg til at funksjonene lar deg importere skriptet til et annet skript (ved å bruke source eller . scriptname.sh, og bruk disse funksjonene som om de var i det nye skriptet.
• At ‘ allerede er dekket i et annet svar.
• Jeg setter pris på det. Men jeg ‘ vil heller la andre mennesker være viktige også.
• Jeg sto overfor en sak i dag hvor jeg måtte omdirigere noe av skriptets utdata til en fil (for å sende det via e-post) i stedet for å ekko. Jeg måtte rett og slett gjøre myFunction > > myFile for å omdirigere utdataene til de ønskede funksjonene. Ganske praktisk. Kan være relevant.

I kommentaren min nevnte jeg tre fordeler med funksjoner:

1. De er lettere å teste og verifisere korrektheten.

2. Funksjoner kan lett gjenbrukes (hentes) i fremtidige skript

3. Sjefen din liker dem.

Og aldri undervurder viktigheten av nummer 3.

Jeg vil ta opp en sak til:

… så det å være i stand til å bytte kjøringsrekkefølgen vilkårlig er ikke noe vi vanligvis gjør. For eksempel vil du ikke «plutselig ønske å sette declare_variables etter walk_into_bar, som ville ødelegge ting.

For å få fordelen av å dele kode inn i funksjoner, bør man prøve å gjøre funksjonene så uavhengige som mulig. Hvis walk_into_bar krever en variabel som ikke brukes andre steder, så skal variabelen defineres i og gjøres lokal til walk_into_bar. Prosessen med å skille koden i funksjoner og minimere deres avhengighet bør gjøre koden klarere og enklere .

Ideelt sett bør funksjoner være enkle å teste hver for seg. Hvis de på grunn av interaksjoner ikke er enkle å teste, er det et tegn på at de kan ha nytte av refactoring.

Kommentarer

• I ‘ d hevder at det ‘ noen ganger er fornuftig å modellere og håndheve disse avhengighetene, mot refactoring for å unngå dem (siden hvis det er nok h av dem, og de ‘ er tilstrekkelig hårete, det kan bare føre til et tilfelle der ting ikke lenger moduleres til funksjoner i det hele tatt). En veldig komplisert brukstilfelle inspirerte en gang et rammeverk til å gjøre nettopp det .
• Det som må deles inn i funksjoner bør være, men eksemplet tar det for langt. Jeg tror den eneste som virkelig bugter meg er funksjonen for variabel deklarasjon. Globale variabler, spesielt statiske, bør defineres globalt i en kommentert del dedikert til det formålet. Dynamiske variabler skal være lokale for funksjonene som bruker og modifiserer dem.
• @Xalorous I ‘ har sett en praksis der globale variabler initialiseres i en prosedyre, som et mellomliggende og raskt trinn før utviklingen av en prosedyre som leser verdien deres fra en ekstern fil … Jeg er enig i at det bør være renere å skille definisjon og initialisering, men sjelden må du bøye deg for å fordel nummer 3 ;-)

Mens jeg er helt enig med gjenbrukbarhet , lesbarhet og kyssende delikat sjefene, men det er en annen fordel med funksjoner 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 ser ikke dette veldig ofte i den virkelige verden shell-skript, men det virker som en god ide for mer komplekse skript. Å redusere samhold hjelper deg med å unngå feil der du klemmer en variabel som forventes i en annen del av koden .

Gjenbrukbarhet betyr ofte å opprette et felles funksjonsbibliotek og source å innføre det biblioteket i alle skriptene dine. Dette hjelper dem ikke til å løpe raskere, men det hjelper deg med å skrive dem raskere.

Kommentarer

• Få mennesker bruker eksplisitt local, men jeg tror de fleste som skriver manus brutt opp i funksjoner, følger fremdeles designprinsippet. Usign local gjør det bare vanskeligere å introdusere bugs.
• local gjør variabler tilgjengelig for å fungere og dets barn, så det ‘ er veldig hyggelig å ha en variabel som kan sendes ned fra funksjon A, men utilgjengelig for funksjon B, som kanskje vil ha variabel med samme navn, men med et annet formål.Slik at ‘ er bra for å definere omfanget, og som Voo sa – mindre feil

Du deler koden i funksjoner av samme grunn som du ville gjort for C / C ++, python, perl, ruby eller hvilken som helst programmeringsspråk-kode. Den dypere grunnen er abstraksjon – du kapsler oppgaver på lavere nivå inn i primitiver (funksjoner) på høyere nivå, slik at du ikke trenger å bry deg om hvordan ting gjøres. Samtidig blir koden mer lesbar (og vedlikeholdbar), og programlogikk blir tydeligere.

Når jeg ser på koden din, synes jeg det er ganske rart å ha en funksjon til å erklære variabler; dette får meg til å heve et øyenbryn.

Kommentarer

• Undervurdert svar IMHO. Foreslår du å erklære variablene i main funksjon / metode, da?

En helt annen årsak fra de som allerede er gitt i andre svar: en grunn til at denne teknikken noen ganger brukes, der den eneste ikke-funksjonsdefinisjonsuttalelse på toppnivå er en oppfordring til main, er å sørge for at skriptet ikke ved et uhell gjør noe stygt hvis skriptet er avkortet. Skriptet kan bli avkortet hvis det er ledes fra prosess A til prosess B (skallet), og prosess A avsluttes uansett årsak før den er ferdig med å skrive hele skriptet. Dette er spesielt sannsynlig at prosess A henter skriptet fra en ekstern ressurs. Mens det ikke er en god ide av sikkerhetsmessige årsaker, er det noe som gjøres, og noen skript er endret for å forutse problemet.

Kommentarer

• Interessant! Men jeg synes det er urovekkende at man må ta vare på disse tingene i hvert av programmene. På den annen side er akkurat dette main() mønsteret vanlig i Python hvor man bruker if __name__ == '__main__': main() på slutten av filen.
• Python-idiomet har fordelen av å la andre skript import gjeldende skript uten å kjøre main. Jeg antar at en lignende vakt kan settes i et bash-skript.
• @Jake Cobb Ja. Jeg gjør det nå i alle nye bash-skript. Jeg har et skript som inneholder en kjerneinfrastruktur for funksjoner som brukes av alle nye skript. Skriptet kan hentes eller kjøres. Hvis den hentes, utføres ikke hovedfunksjonen. Oppdagelse av kilde mot utførelse skjer via det faktum at BASH_SOURCE inneholder navnet på det utførende skriptet. Hvis det ‘ er det samme som kjerneskriptet, blir skriptet utført. Ellers blir det ‘ hentet.
• Nært knyttet til dette svaret bruker bash enkel linjebasert behandling når den kjører fra en fil som allerede er på disken. Hvis filen endres mens skriptet kjører, endres linjetelleren ikke ‘ t, og den ‘ fortsetter på feil linje. Innkapsling av alt i funksjoner sikrer at ‘ er lastet inn i minnet før du kjører noe, så endring av filen påvirker ikke t.

Noen relevante truisms om programmering:

• Programmet ditt vil endres, selv om sjefen din insisterer på at dette ikke er tilfelle.
• Bare kode og inndata påvirker oppførselen til programmet.
• Det er vanskelig å navngi .

Kommentarer starter som et stoppgap for ikke å være i stand til å uttrykke ideene dine tydelig i kode *, og bli verre (eller rett og slett feil) med endring. Hvis det i det hele tatt er mulig, uttrykker du derfor konsepter, strukturer, resonnement, semantikk, flyt, feilhåndtering og alt annet som er relevant for forståelsen av koden som kode.

Når det er sagt, Bash-funksjoner har noen problemer som ikke finnes på de fleste språk:

• Navneavstand er forferdelig i Bash. Hvis du for eksempel glemmer å bruke søkeordet local, forurenser det det globale navneområdet.
• Bruk av local foo="$(bar)" resulterer i mister utgangskoden til bar .
• Det er ingen navngitte parametere, så du må huske på hva "$@" betyr i forskjellige sammenhenger.

* Jeg beklager hvis dette krenker, men etter ved å bruke kommentarer i noen år og utvikle seg uten dem ** i flere år, er det ganske klart hva som er overlegen.

** Å bruke kommentarer til lisensiering, API-dokumentasjon og lignende er fortsatt nødvendig.

Kommentarer

• Jeg satte nesten alle lokale variabler ved å erklære dem null i begynnelsen av funksjonen …local foo="" Deretter setter du dem ved hjelp av kommandokjøring for å handle på resultatet … foo="$(bar)" || { echo "bar() failed"; return 1; }. Dette får oss raskt ut av funksjonen når en ønsket verdi ikke kan settes. De krøllete bukseselene er nødvendige for å sikre at return 1 bare utføres ved feil.
• Ville bare kommentere punktene dine. Hvis du bruker ‘ subshell-funksjoner ‘ (funksjoner avgrenset av parentes og ikke krøllete parenteser), donerer du 1) ‘ må ikke bruke lokalt, men få fordelene med lokalt, 2) Ikke ‘ t løp inn i problemet med å miste utgangskoden for kommandosubstitusjon i local foo=$(bar) like mye (fordi du ‘ ikke bruker lokal) 3) Ikke ‘ t trenger å bekymre deg om forurensing ved uhell eller endring av globalt omfang 4) er i stand til å sende ‘ navngitte parametere ‘ som er ‘ lokal ‘ til din funksjon ved å bruke syntaksen foo=bar baz=buz my-command

En prosess krever en sekvens. De fleste oppgaver er sekvensielle. Det gir ingen mening å rote med ordren.

Men den super store tingen med programmering – som inkluderer skripting – er testing. Testing, testing, testing. Hvilke testskripter har du for øyeblikket for å validere riktigheten av skriptene dine?

Sjefen din prøver å veilede deg fra å være et kiddy-skript til å være programmerer. Dette er en god retning å gå i. Folk som kommer etter deg, vil like deg.

MEN. Husk alltid dine prosessorienterte røtter. Hvis det er fornuftig å ha funksjonene ordnet i sekvensen som de vanligvis utføres i, gjør det, i det minste som et første pass.

Senere vil du se at noen av funksjonene dine er håndtering av inngang, andre utdata, andre behandler, andre modellerer data og andre manipulerer dataene, så det kan være smart å gruppere lignende metoder, kanskje til og med flytte dem til separate filer.

Senere, kan du kom til å innse at du nå har skrevet biblioteker med små hjelperfunksjoner som du bruker i mange av skriptene dine.

Kommentarer og avstand kan ikke komme i nærheten av lesbarheten som funksjoner kan, som jeg vil demonstrere. Uten funksjoner kan du ikke se skogen for trærne – store problemer gjemmer seg blant mange detaljeringslinjer. Med andre ord kan folk ikke fokusere samtidig på de fine detaljene og på det store bildet. Det er kanskje ikke åpenbart i et kort manus. Så lenge det er kort, kan det være lesbart nok. Programvaren blir større, men ikke mindre , og absolutt er det en del av hele programvaresystemet til firmaet ditt, som sikkert er veldig mye større, sannsynligvis millioner av linjer.

Tenk om jeg ga deg instruksjoner som dette:

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 halvveis, eller til og med 5% gjennom, ville du ha glemt hva de første trinnene var. Du kunne muligens ikke oppdage de fleste problemer, fordi du ikke kunne se skogen for trærne. Sammenlign med funksjoner:

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

Det er absolutt mye mer forståelig, uansett hvor mange kommentarer du kan legge i den linje-for-linjen sekvensielle versjonen. Det gjør det også langt mer sannsynlig at du «vil legge merke til at du har glemt å lage kaffen, og glemte sannsynligvis sit_down () på slutten. Når tankene dine tenker på detaljene i grep og awk regexes, kan du ikke tenke stort bilde – «hva om det ikke er laget kaffe»?

Funksjoner lar deg først og fremst se det store bildet, og legg merke til at du har glemt å lage kaffen (eller at noen kanskje foretrekker te). På et annet tidspunkt, i en annen tankegang, bekymrer du deg for den detaljerte implementeringen.

Det er også andre fordeler diskutert i andre svar, selvfølgelig. En annen fordel som ikke er tydelig angitt i de andre svarene, er at funksjoner gir en garanti som er viktig for å forhindre og fikse feil. Hvis du oppdager at en eller annen variabel $ foo i riktig funksjon walk_to () var feil, vet du at du bare trenger å se på de andre 6 linjene i den funksjonen for å finne alt som kan ha blitt påvirket av det problemet, og alt som kan har fått det til å være feil. Uten (riktige) funksjoner kan alt og alt i hele systemet være en årsak til at $ foo er feil, og alt og alt kan bli påvirket av $ foo. Derfor kan du ikke trygt fikse $ foo uten å undersøke hver eneste linje i programmet på nytt. Hvis $ foo er lokal for en funksjon, kan du garantere at eventuelle endringer er sikre og korrekte ved å bare sjekke den funksjonen.

Kommentarer

• Dette er ikke ‘ t bash syntaksen.Det er ‘ synd; Jeg tror ikke ‘ det er en måte å overføre input til slike funksjoner. (dvs. pour(); < coffee). Det ser mer ut som c++ eller php (tror jeg).
• @ tjt263 uten parentes, det ‘ s bash-syntaks: hell kaffe. Med parens er det ‘ stort sett alle andre språk. 🙂

Time is money

Det er andre gode svar som sprer lys over de tekniske grunnene til å skrive modulært et skript, potensielt lang, utviklet i et arbeidsmiljø, utviklet for å brukes av en gruppe personer og ikke bare for eget bruk.

Jeg vil fokus på en forventer: i et arbeidsmiljø «tid er penger» . Så fraværet av feil og ytelsen til koden din blir evaluert sammen med lesbarhet , testbarhet, vedlikeholdbarhet, refaktorabilitet, gjenbrukbarhet> div id = «abce182223»>

En annen grunn som ofte blir oversett, er bash «s syntax parsing:

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

Dette skriptet inneholder åpenbart en syntaksfeil og bash burde ikke kjøre det i det hele tatt, ikke sant? Feil.

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

Hvis vi pakket koden i en funksjon, ville dette ikke skje:

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 

Bortsett fra årsakene i andre svar:

9. Psykologi: En programmerer hvis produktivitet blir målt i kodelinjer, vil ha et incitament til å skrive unødvendig detaljert kode. Jo mer ledelse er med fokus på kodelinjer, jo mer insentiv har programmereren å utvide koden med unødvendig kompleksitet. Dette er uønsket siden økt kompleksitet kan føre til økte vedlikeholdskostnader og økt innsats som kreves for feilretting.
   • WP, kildelinjer for kode; Ulemper, # 9

Kommentarer

• Det er ikke så dårlig svar, som nedstemningene sier. Merk: agc sier, dette er også en mulighet, og ja, det er det. Han sier ikke ‘ det ville være den eneste muligheten, og ikke ‘ t anklager noen, bare uttaler fakta. Selv om jeg tror i dag er nesten uhørt, er en direkte » kodelinje » – > » $$ » stilkontraktsjobb, på indirekte betyr det at det er ganske vanlig at ja, massen av den produserte koden teller av lederne / sjefer.