Om du hittade den här sidan i en sökning försöker du förmodligen lösa något problem med att köra bash.
Din bash-miljö kanske inte ställer in en miljövariabel och du förstår inte varför. Du kan ha fastnat något i olika bash boot-filer eller profiler eller alla filer på måfå tills det fungerade.
I vilket fall som helst är poängen med denna anteckning att lägga ut proceduren för att starta bash så enkelt som möjligt så att du kan hantera problem.
Диаграмма
Detta flödesschema sammanfattar alla processer när du kör bash.
Låt oss nu titta närmare på varje del.
Logga in Shell?
Först måste du välja om du är i inloggningsskalet eller inte.
Inloggningsskalet är det första skalet du anger när du loggar in för en interaktiv session. Inloggningsskalet kräver inget användarnamn och lösenord. Du kan tvinga inloggningsskalet att starta genom att lägga till en flagga --login när man ringer bash, till exempel:
bash --logga in
Inloggningsskalet ställer in basmiljön när du först startar bash-skalet.
Interaktiv?
Sedan avgör du om skalet är interaktivt eller inte.
Detta kan kontrolleras genom närvaron av variabeln PS1 (den installerar kommandoinmatningsfunktionen):
if [ "${PS1-}" ]; sedan echo interactive annars eko icke-interaktiv fi
Eller se om alternativet är inställt -i, med hjälp av en speciell bindestrecksvariabel - i bash, till exempel:
$echo$-
Om det finns en symbol i utgången i, då är skalet interaktivt.
I inloggningsskalet?
Om du är i ett inloggningsskal letar bash efter filen /etc/profile och körs om det finns.
Söker sedan efter någon av dessa tre filer i följande ordning:
~/.bash_profile ~/.bash_login ~/.profile
När den hittar en startar den den och hoppar över de andra.
I ett interaktivt skal?
Om du är i ett icke-inloggningsskal, antas det att du redan har varit i ett inloggningsskal, miljön är konfigurerad och kommer att ärvas.
I det här fallet körs följande två filer i ordning, om de finns:
/etc/bash.bashrc ~/.bashrc
Inget alternativ?
Om du inte är i antingen ett inloggningsskal eller ett interaktivt skal, kommer din miljö verkligen att vara tom. Detta orsakar mycket förvirring (se nedan om cron-jobb).
I det här fallet tittar bash på variabeln BASH_ENV din miljö och skapar motsvarande fil som anges där.
Vanliga svårigheter och tumregler
cron jobb
95% av tiden jag felsöker bash-start beror det på att cron-jobbet inte körs som förväntat.
Denna jäkla uppgift fungerar bra när jag kör det på kommandoraden, men misslyckas när jag kör det i crontab.
Här två skäl:
- Cron-jobb är inte interaktiva.
- Till skillnad från kommandoradsskript, ärver inte cron-jobb skalmiljön.
Vanligtvis kommer du inte att märka eller bry dig om att ett skalskript inte är interaktivt eftersom miljön ärver från det interaktiva skalet. Det betyder att allt PATH и alias konfigurerad som du kan förvänta dig.
Det är därför det ofta är nödvändigt att ställa in en specifik PATH för en cron-uppgift som här:
* * * * * PATH=${PATH}:/path/to/my/program/folder myprogram
Manus som ringer varandra
Ett annat vanligt problem är när skript av misstag konfigureras för att anropa varandra. Till exempel, /etc/profile tilltalar ~/.bashrc.
Detta händer vanligtvis när någon försökte fixa något fel och allt verkade fungera. Tyvärr, när du behöver separera dessa olika typer av sessioner, uppstår nya problem.
Sandboxed Docker-bild
För att experimentera med att köra ett skal skapade jag en Docker-avbildning som kan användas för att felsöka att köra ett skal i en säker miljö.
Lansera:
$ docker run -n bs -d imiell/bash_startup
$ docker exec -ti bs bashDockerfile finns .
Så här tvingar du inloggning och simulerar ett inloggningsskal:
$ bash --login
För att testa en uppsättning variabler BASH_ENV:
$ env | grep BASH_ENV
För felsökning crontab ett enkelt skript kommer att köras varje minut (i /root/ascript):
$ crontab -l
$ cat /var/log/script.logKälla: will.com