Starta Bash i detalj

Om du har hittat denna sida via sökningen, försöker du antagligen lösa ett problem med att starta bash.

Kanske sätts inte miljövariabeln i din bash-miljö och du förstår inte varför. Kanske har du tryckt in något i olika bash-startfiler eller profiler, eller i alla filer slumpmässigt, tills det fungerade.

Oavsett vilket är syftet med denna anteckning att så enkelt som möjligt beskriva proceduren för att starta bash, så att du kan hantera problemen.

Diagram

Detta flödesschema sammanfattar alla processer vid start av bash.

Låt oss nu titta närmare på varje del.

Inloggningsshell?

Först måste du avgöra om du befinner dig i en inloggningsshell eller inte.

En inloggningsshell är den första shell du hamnar i när du loggar in på systemet för en interaktiv session. Inloggningsshellen kräver inget användarnamn eller lösenord. Du kan tvinga att starta inloggningsshellen genom att lägga till flaggan --login vid anropet bash, till exempel:

bash --login

Inloggningsshellen ställer in den grundläggande miljön vid den första starten av bash-shellet.

Interaktiv?

Därefter bestämmer du om shellen är interaktiv eller inte.

Detta kan kontrolleras genom att titta på om variabeln PS1 (den ställer in kommandoinmatningsfunktionaliteten):

if [ "${PS1-}" ]; then
  echo interactive
else
  echo non-interactive
fi

Eller genom att se om parametern -i, med speciell variabel med ett bindestreck - i bash, till exempel:

$ echo $-

Om det finns en symbol i, är shellen interaktiv.

I inloggningsshell?

Om du befinner dig i en inloggningsshell, letar bash efter filen /etc/profile och kör den om den finns.

Sedan söker den efter någon av dessa tre filer i följande ordning:

~/.bash_profile
~/.bash_login
~/.profile

När den hittar en kör den den och hoppar över de andra.

I interaktiv shell?

Om du är i en interaktiv shell utan inloggning (non-login shell) antas det att du redan har varit i en inloggningsshell, miljön har ställts in och kommer att ärvas.

I det här fallet körs följande två filer i ordning, om de finns:

/etc/bash.bashrc
~/.bashrc

Ingen av alternativen?

Om du varken är i en inloggningsshell eller en interaktiv shell, kommer din miljö verkligen att vara tom. Detta orsakar stor förvirring (se nedan angående cron-jobb).

I detta fall tittar bash på variabeln BASH_ENV i din miljö och skapar den angivna filen där.

Typiska svårigheter och tumregler

Cron-jobbar

I 95% av fallen är felsökning av bash-körningar kopplad till att cron-jobbet inte fungerar som förväntat.

Det här hemska jobbet fungerar fint när jag kör det från kommandoraden, men misslyckas när det körs i crontab..

Här Två orsaker:

• Cron-jobb är inte interaktiva.
• Till skillnad från skript som körs i kommandoraden är cron-jobb intevervingar miljön från skalet.

Ofta märker eller bryr du dig inte om att skriptet inte är interaktivt, eftersom miljön ärvs från det interaktiva skalet. Det betyder att allt PATH och alias är inställt som du förväntar dig.

Det är därför man ofta behöver ställa in en specifik PATH för cron-jobbet, som här:

* * * * * PATH=${PATH}:\/path\/to\/my\/program\/folder myprogram

Skript som kallar på varandra

En annan vanlig problematik är när skript felaktigt konfigureras för att anropa varandra. Till exempel, /etc/profile ansluter till ~/.bashrc.

Detta händer ofta när någon försökt fixa ett fel och det verkar ha fungerat. Tyvärr, när man behöver separera dessa olika typer av sessioner, uppstår nya problem.

Docker-image i sandlådan

För att experimentera med att köra skalet, har jag skapat en Docker-image som kan användas för att felsöka körning av skalet i en säker miljö.

Starta:

$ docker run -n bs -d imiell\/bash_startup
$ docker exec -ti bs bash

Dockerfile finns här.

För att tvinga inloggning och simulera inloggningsskal:

$ bash --login

För att kontrollera uppsättningen av variabler BASH_ENV:

$ env | grep BASH_ENV

För felsökning crontab ett enkelt skript körs varje minut (i /root/ascript):

$ crontab -l
$ cat \/var\/log\/script.log

Källa: habr.com