Linux-kommandon och skalfärdigheter
Bash Scripting: Från "works on my box" till produktion
Bash får sin plats när en uppgift är klistrad: orkestrera kommandon, bråka enkel text och håll dig helt på lådan. Dess branschrykte kommer från landningen, inte idén: oprövade pipelines skickas till cron på en server där en variabel var inställd eller ett filnamn hade ett mellanslag. Disciplinen är mekanisk och billig, och den har fyra delar: strikt läge, citering, shellcheck och loggning så som ops kommer att läsa det senare.
Nyckelpunkter
- Varje seriöst skript öppnas med set -euo pipefail: oinställda variabler misslyckas, kommandofel stoppar skriptet, pipeline ligger på ytan; utan det passerar felen tyst tills de når produktionen.
- Citatvariabler och kommandosubstitutioner: "$var" och "$(cmd)"; orddelning på mellanslag är klassikern genom tiderna, och det IFS-fiffel som vissa sajter rekommenderar är en bugg som du väljer att komma ihåg.
- Klammerexpansion sker före variabler: rm -rf "${CLEANUP:?}"/{a,b} med CLEANUP unset expanderar annorlunda än tänkt och tar bort saker du tänkt behålla; ${VAR:?} kontroller är rm-säkerhetsspråket värt att lära sig en gång.
- shellcheck får sin plats vid varje förändring: den fångar globs utan citat, oåtkomlig kod och 'for f in $(ls)'-mönster som äter filnamn med mellanslag; kör den i CI och buggarna slutar nå cron.
- Temp-arbete och rengöring är ihopparade: TMP=$(mktemp -d), trap 'rm -rf "$TMP"' EXIT och inga föräldralösa scratch-dirs plus inga "if error then remove" strössel på varje gren.
- Lässlingor på ett säkert sätt: medan IFS= read -r -d '' f hanterar filnamn med nyrader och mellanslag via find -print0; 'för f i $(ls)' är buggskalkontrollflaggor och gamla skript överallt fortfarande bär.
- Avsluta koder och loggar talar till ops: eko misslyckanden till stderr (>&2) med ett scennamn, avsluta nonnoll vid verkligt misslyckande, och låt crons post eller journal visa dig den rad du faktiskt behöver klockan 3 på morgonen.
- Eskalera tidigt: JSON-parsning, tre plus nivåer av kapsling, HTTP-anrop eller någon tillståndsbestämd logik hör hemma i Python eller awk; bash böjd till ett allmänt språk är där dess rykte förtjänades.
Fältnotis
Vårt brace-expansion scar: rm -rf "${CLEANUP}"/{a,b} med CLEANUP unset expanderade precis så som skalet, inte avsikten, ville. Varje väg som den bär nu ${VAR:?}-vakten, och ingen har betalat den räkningen två gånger.
Vanliga frågor
#!/bin/bash eller #!/usr/bin/env bash?
env vinner över behållare och macOS-installationer där bash bor någon annanstans; shebang spelar mindre roll än set -euo pipefail är faktiskt närvarande och shellcheck skickar vidare varje förändring.
Mitt skript fungerar manuellt men misslyckas i cron. Varför?
Cron körs med bar miljö: PATH är kort, det finns ingen inloggningsprofil och relativa vägar pekar på fel hem. Använd absoluta sökvägar, ställ in PATH explicit och håll bash -x replay för felsökning.
Bash eller Python för serveruppgifter?
Bash för pipelines som mestadels orkestrerar befintliga systemverktyg och förblir små; Python för strukturerad data, API:er och felhantering som måste överleva jour. Att tvinga bash att spela Python är hur incidenter får namn.
Hur skriptar jag borttagningar på ett säkert sätt?
Citera varje variabel, rikta endast in mktemp-producerade eller explicit konfigurerade sökvägar, kör med ett torrkörningsläge som skriver ut vad den skulle ta bort, och låt en ${VAR:?} bevaka avaktiverade variabler innan rm ser dem.
Så hjälper Kinetikatech dig med linux-kommandon och skalfärdigheter
Du ska inte behöva bli expert på linux-kommandon och skalfärdigheter: Kommandon och skriptvanor som avgör om en administratör driver en server eller bekämpar den: sök, transformera, överföra och övervaka text och processer med verktygen som finns i varje basinstallation. Det är precis vad Linux-serversäkerhet och Serverhantering finns till för, installation, härdning, övervakning och en människa på jour dygnet runt.