Ha megtalálta ezt az oldalt a keresés során, valószínűleg valamilyen problémát próbál megoldani a bash futtatásával.
Lehet, hogy a bash környezeted nem állít be környezeti változót, és nem érted, miért. Előfordulhat, hogy beragadt valamit a különböző bash rendszerindító fájlokban vagy profilokban, vagy véletlenszerűen az összes fájlban, amíg nem működött.
Mindenesetre ennek a megjegyzésnek az a lényege, hogy a lehető legegyszerűbben leírja a bash indításának eljárását, hogy kezelni tudja a problémákat.
Diagram
Ez a folyamatábra összefoglalja az összes folyamatot a bash futtatásakor.
Most nézzük meg közelebbről az egyes részeket.
Bejelentkezés Shell?
Először ki kell választania, hogy a bejelentkezési shellben van-e vagy sem.
A login shell az első shell, amelyet beír, amikor bejelentkezik egy interaktív munkamenetbe. A bejelentkezési shell nem igényel felhasználónevet és jelszót. A bejelentkezési parancsértelmezőt egy jelző hozzáadásával kényszerítheti indulásra --login amikor hívják bash, például:
bash -- bejelentkezés
A bejelentkezési shell a bash shell első indításakor állítja be az alapkörnyezetet.
Interaktív?
Ezután meghatározza, hogy a shell interaktív-e vagy sem.
Ez a változó jelenlétével ellenőrizhető PS1 (telepíti a parancsbeviteli funkciót):
if [ "${PS1-}" ]; akkor visszhang interaktív else echo nem interaktív fi
Vagy nézze meg, hogy be van-e állítva az opció -i, speciális kötőjel változó használatával - bash-ban például:
$echo$-
Ha a kimenetben van egy szimbólum i, akkor a shell interaktív.
A bejelentkezési shellben?
Ha egy login shellben vagy, akkor a bash megkeresi a fájlt /etc/profile és fut, ha létezik.
Ezután megkeresi a három fájl bármelyikét a következő sorrendben:
~/.bash_profile ~/.bash_login ~/.profile
Amikor talál egyet, elindítja, és kihagyja a többit.
Interaktív héjban?
Ha nem bejelentkező shellben tartózkodik, akkor a rendszer feltételezi, hogy már volt bejelentkezési shellben, a környezet be van állítva, és öröklődik.
Ebben az esetben a következő két fájl kerül végrehajtásra sorrendben, ha vannak:
/etc/bash.bashrc ~/.bashrc
Nincs lehetőség?
Ha nem vagy bejelentkezési shellben vagy interaktív shellben, akkor a környezeted valóban üres lesz. Ez sok zavart okoz (lásd alább a cron feladatokról).
Ebben az esetben a bash a változót nézi BASH_ENV környezetében, és létrehozza az ott megadott megfelelő fájlt.
Gyakori nehézségek és hüvelykujjszabályok
cron munkák
Az esetek 95%-ában a bash indításakor hibakereső vagyok, mert a cron job nem a várt módon fut.
Ezt az átkozott feladatot jól működik, ha parancssorban futtatom, de nem működik, ha crontabban futtatom.
Itt két ok:
- A Cron jobok nem interaktívak.
- A parancssori szkriptekkel ellentétben a cron jobok nem öröklik a shell környezetet.
Általában nem veszi észre, és nem is törődik vele, hogy egy shell szkript nem interaktív, mert a környezet az interaktív shelltől örökli. Ez azt jelenti, hogy minden PATH и alias az elvárásoknak megfelelően konfigurálva.
Ezért gyakran szükséges egy konkrét beállítást PATH egy cron feladathoz, mint itt:
* * * * * PATH=${PATH}:/elérésiútja/saját/programom/mappa programomhoz
Egymást hívó szkriptek
Egy másik gyakori probléma az, amikor a parancsfájlokat tévesen úgy konfigurálják, hogy hívják egymást. Például, /etc/profile apellál ~/.bashrc.
Ez általában akkor történik, amikor valaki megpróbált kijavítani valamilyen hibát, és úgy tűnt, hogy minden működik. Sajnos, amikor szét kell választani ezeket a különböző típusú munkameneteket, új problémák merülnek fel.
Sandboxed Docker kép
A shell futtatásával kapcsolatos kísérletezéshez létrehoztam egy Docker-képet, amellyel biztonságos környezetben lehet hibakeresni egy shellt.
Dob:
$ docker run -n bs -d imiell/bash_startup
$ docker exec -ti bs bashDockerfile található .
A bejelentkezés kényszerítése és a bejelentkezési shell szimulálása:
$ bash --login
Változókészlet tesztelése BASH_ENV:
$ env | grep BASH_ENV
Hibakereséshez crontab percenként egy egyszerű szkript fut le (in /root/ascript):
$ crontab -l
$ cat /var/log/script.logForrás: will.com