Vill lära mig scripta i Bash

Som skrevs ovan: Bash är Bash, oavsett vilket system du kör det på. Har du Bash installerat så har du (OS X kommer med Bash som standard, vad jag vet). Sedan kan det finnas skillnader mellan äldre och nyare versioner av Bash, men det är sällan ett bekymmer i min erfarenhet, då det är ett moget projekt.

Vad du kanske egentligen menar när du skriver Bash är "shell script", dvs generella skalskript. Bash är ett skal bland många, men den gemensamma nämnaren är snarare det som är definierat i POSIX.

Bash är (med rätta) populärt att använda som interaktivt skal, dvs det gränssnitt som gäller när du skriver i "terminalen". Bash kommer med stöd för tangentbordskommandon, tabbkomplettering och en mängd saker, inte minst genom dess Readline-integrering.

När man skriver ett skalskript i en fil och ber systemet exekvera denna så bestämmer man ofta tolk genom en shebang i början av filen. Skriver man

#!/bin/bash

så säger man åt systemet att använda just Bash som tolk. Dock så kommer du märka att det är klart vanligare ("citation needed", men men) att se

#!/bin/sh

vilket kan betyda Bash, beroende på system, men inte måste göra det. På Debian-baserade system (Ubuntu, Mint, etc.) så betyder det inte Bash, utan Dash. Dash är tänkt att vara ett strikt POSIX-kompatibelt skal utan alla "bells and whistles" som Bash inkluderar. Detta gör att Dash i jämförelse med Bash är

• snabbare: det är mindre bagage att behöva dra igång, färre konstruktioner att behöva tolka, etc.

• säkrare: med mindre funktionalitet är det mycket lättare att säkra upp kodbasen (cf. shell shock).

Ubuntus wiki har en del övergripande information om varför ändringen gjordes och om skillnaderna mellan skalen. Notera alltså att dessa system fortfarande använder Bash som standard för interaktiv användning, men Dash som standard för icke-interaktiva (dvs som körs utan att användaren själv skriver varje rad i tolken) skript.

För att stanna lite på "shell shock"-spåret så var en majoritet av problemet där att många system (exempelvis RHEL-baserade sådana) använde Bash som /bin/sh, vilket gjorde att när ett hål i Bashs mycket större kodbas upptäcktes så var helt plötsligt alla skalskript i skottgluggen, även de som egentligen absolut inte behövde köras med Bash, och inte ens explicit angavs med en sådan shebang. Läxa: använd inte Bash till icke-interaktiva skript om det inte är nödvändigt (vilket det sällan är).

Så: när du säger att du vill lära dig skripta i Bash så menar du nog egentligen att du vill lära dig "shell script". Bash kan enkelt sägas vara en utökad variant av detta.

Själv försöker jag vara väldigt tydlig med att bara skriva #!/bin/bash och använda dessa utökade funktioner när det verkligen, verkligen behövs (och det är ultrafel att skriva #!/bin/sh och ändå kallt anta att det betyder "Bash", vilket folk fortfarande gör i tid och otid, vilket sänker portabiliteten till fotknölarna). Personligen så brukar det handla om rätt exotiska situationer där man märker att Bashs vektorhantering skulle kunna förenkla saker betydligt, men i all ärlighet så om skriptet börjar bli alltför komplext så är det ofta värt att gå över till exempelvis Python i stället (efter att ha skrivit min beskärda del av både Perl och Python så väljer jag medvetet att inte förespråka Perl här, men det kan vara material för en separat flametråd… ).

Ett större problem vad gäller kompatibilitet mellan olika system när man skriptar (dvs om vi antar att man lärt sig skillnaden mellan Bash och POSIX) är vilken version av sidoprogrammen som finns installerade.

En typisk sak med skalskript är att man kallar på externa klassiska *nix-verktyg som mv, find, grep, sed, awk, etc., och sitter du på ett fullskaligt Linuxbaserat system så är detta ofta synonymt med GNU:s varianter av dessa verktyg, som ofta har lite extra (oerhört smidig) funktionalitet inkluderad — lite analogt med förhållandet mellan Bash och POSIX-skript. Utgår man då ifrån att dessa specialfunktioner existerar så går saker lätt åt pipan om man flyttar sina skript till ett system som kanske använder BSD-verktygen eller minimala uppsättningar som Busybox. De senare nämnda följer också POSIX-specifikationerna för sina respektive verktyg, men GNU-versionerna lägger alltså till lite extra saker. Exempelvis OS X använder inte GNU-verktygen som standard (åtminstone kan man inte förlita sig på det).

Skillnaderna mellan verktygen är dokumenterade, och så länge man är medveten om att det kan vara skillnad så lär man sig dessa med tiden.

"Learning by doing" är i mina ögon sätt nummer 1, med god marginal. Kom på något du själv har användning av att automatisera och skriv skript för detta. Under tiden så kommer du googla vilt, och då trilla in på ställen som Greg's wiki (handlar om Bash, men överlappet är rätt stort, förutom när det inte är det ), Superuser och Unix.SX där du förhoppningsvis lär dig något av värde. Jag tror att shell script i synnerhet är svårt att "lära sig" syntetiskt, dvs genom att bara titta på andras exempel. Använder du terminalen i ett *nix-system praktiskt så kommer du under tiden organiskt se tillfällen för skriptande. Jag har tidigare skrivit något liknande här på forumet.

Introduction to the Command Line [FLOSS Manuals] är annars en någorlunda trevlig och lättsmält introduktion till många aspekter av terminalen. The Bash Guide är en annan mer massiv introduktion till specifikt Bash (en sorts återfödelse av Greg's wiki enligt upphovspersonen), men som sagt är det en del överlapp.

Skriptspråket i sig är rätt begränsat i någon mån, så det tar inte lång tid att lära sig definiera variabler och skriva villkorssatser, loopar och funktioner. Det som tar tid att få in är en mängd detaljer, så som hur

• regler för fältsplittning fungerar (vad är $IFS och varför behöver man bry sig?)

• felhantering sköts; hur man använder trap och hanterar signaler

• vettiga gränssnitt för skript definieras; hur getopts fungerar

• alla skrymslen och vrår av variabelsubstitution/interpolation ser ut, och hur detta kan sköta den mesta stränghanteringen direkt i skalet

• saker som pipes, buffring, fildeskriptorer, subskal, etc., fungerar och interagerar

och mycket mer därtill. Liksom nämnts så är en annan viktig läxa att lära sig vad man inte bör använda skalskript till, dvs att veta när man bör "överge skeppet". Det lär man sig ofta den hårda vägen.

Dessutom ligger den allra största styrkan i shell script i att ha koll på andra verktyg. Man bör ha viss pejl på cp, mv, ln, cut, find, sort, head, tail, stat, tr, wc, uniq, etc., och veta när de passar att använda. Dessutom bör man kunna hantera grep, sed, awk, etc., som på många sätt är fullständiga språk helt på egen hand.

Det kan låta som mycket, och det är det, men jag skulle säga att det åtminstone inte är speciellt komplicerat (möjligen förutom sed och framför allt awk ). Dessutom så är det alltså kunskap som enklast "sipprar in" närapå automatiskt genom långvarig och regelbunden användning av *nix-system.

Jag har från en säker källa hört att informationen i FAQ-tråden Introduktion till och överblick av Linux och övriga operativsystem är av högsta klass!