Als u deze pagina via een zoekopdracht hebt gevonden, probeert u waarschijnlijk een probleem met het opstarten van bash op te lossen.
Misschien is in uw omgeving de omgevingsvariabele voor bash niet ingesteld en begrijpt u niet waarom. Misschien heeft u iets in verschillende opstartbestanden van bash of in profielen gestopt, of in alle bestanden zomaar, totdat het werkte.
Hoe dan ook, het doel van deze opmerking is om de procedure voor het opstarten van bash zo eenvoudig mogelijk uit te leggen, zodat u met de problemen kunt omgaan.
Diagram
Dit stroomdiagram geeft een overzicht van alle processen bij het opstarten van bash.
Laten we nu elke parte gedetailleerd bekijken.
Login Shell?
Eerst moet u bepalen of u zich in een login shell bevindt of niet.
Een login shell is de eerste shell waar u in terechtkomt bij inloggen voor een interactieve sessie. Een login shell vereist geen invoer van gebruikersnaam en wachtwoord. U kunt de login shell forceren door de vlag toe te voegen aan --login bij de oproep, dus alle bash, bijvoorbeeld:
bash --login
De login shell configureert de basisomgeving bij de eerste start van de bash shell.
Interactief?
Vervolgens bepaalt u of de shell interactief is of niet.
Dit kunt u controleren aan de hand van de variabele PS1 (deze stelt de invoerfunctie in):
if [ "${PS1-}" ]; then
echo interactive
else
echo non-interactive
fi Of kijk of de parameter -iis ingesteld door gebruik te maken van de speciale min variabele - in bash, bijvoorbeeld:
$ echo $-
Als in de uitvoer het teken istaat, is de shell interactief.
In de login shell?
Als u in een login shell bent, zoekt bash naar het bestand /etc/profile en voert het uit, als het bestaat.
Daarna zoekt het naar een van deze drie bestanden in bovenstaande volgorde:
~/ .bash_profile ~/ .bash_login ~/ .profile
Wanneer het er een vindt, voert het deze uit en slaat de andere over.
In de interactieve shell?
Als u in een interactieve shell zonder inloggen bent (non-login shell), wordt aangenomen dat u al in een login shell bent geweest, de omgeving is ingesteld en zal worden geërfd.
In dat geval worden, als ze bestaan, de volgende twee bestanden in volgorde uitgevoerd:
/etc/bash.bashrc ~/.bashrc
Geen van beide opties?
Als u zich in geen login shell of interactieve shell bevindt, zal uw omgeving echt leeg zijn. Dit leidt tot veel verwarring (zie hieronder over cron-taken).
In dat geval kijkt bash naar de variabele BASH_ENV van uw omgeving en maakt het bestand aan dat daar is opgegeven.
Typische moeilijkheden en vuistregels
Cron-taken
In 95% of cases, debugging bash startup is related to the cron job not working as expected.
This cursed task works fine when I run it in the command line, but fails when launched in crontab.
Hier two reasons:
- Cron jobs are not interactive.
- Unlike command line scripts, cron jobs do not inherit the shell environment.
You usually don’t notice or care that the shell script is not interactive because the environment is inherited from an interactive shell. This means that all PAD en beheer van afbeeldingsaliassen are configured as you expect.
That’s why it’s often necessary to set a specific PAD for the cron job, like this:
* * * * * PATH=${PATH}:\/path\/to\/my\/program\/folder myprogramScripts calling each other
Another common problem is that scripts mistakenly set up to call each other. For example, /etc/profile accesses ~/\.bashrc.
This usually happens when someone tries to fix a bug and everything seems to work. Unfortunately, when it comes to separating these different types of sessions, new problems arise.
The Docker image in the sandbox
To experiment with shell startup, I created a Docker image that can be used to debug shell startup in a safe environment.
Run:
$ docker run -n bs -d imiell\/bash_startup
$ docker exec -ti bs bashThe Dockerfile is located .
For forced login and simulating a login shell:
$ bash --login To check the set of variables BASH_ENV:
$ env | grep BASH_ENV For debugging crontab a simple script will run every minute (in /root/ascript):
$ crontab -l
$ cat \/var\/log\/script.logBron: habr.com
