A legjobb válasz
Köszönöm az A2A-t.
Úgy gondolom, hogy Anmol Vishwakarma kiváló leírást adott a számít.
Csak azért, hogy a dolgokat perspektívába helyezzük:
- / etc / profile, ~ / .bash\_rc , és ~ / .bash\_profile, mind fájl, és ezeket c onfiguration parancsfájloknak hívják. Tartalmazhatnak változó deklarációkat, változók exportálását, a bejelentkezéskor végrehajtandó parancsokat, például e-mail vagy hírek ellenőrzését, többek között az umask beállítását. A felhasználók tipikus dolgai a következők: néhány dir hozzáadása a $ PATH-hoz, néhány változó exportálása, $ PS1 megváltoztatása, a kijelző színeinek beállítása, üdvözlő szöveges üzenet hozzáadása stb.
- Mindezek a fájlok, kivéve a / etc / profile, alapértelmezés szerint rejtve vannak, ahogyan azt a vezető pont jelöli (tehát nem bash\_profile , hanem valójában .bash\_profile ).
- Amikor bejelentkezel (akár helyileg, akár távolról), akkor ezt nevezzük bejelentkezési héjnak, és kicsit kezeljük kicsit eltér a normál héjhívástól. Ebben az esetben a / etc / profile fájl végrehajtása megtörténik, amely után vagy egy ~ /.bash\_profile vagy egy ~ / .bashrc fájlt futtatnak, ebben a sorrendben.
- Interaktív shell, azaz az, akivel kölcsönhatásba léphet, mert a shell stdin és stderr egyaránt TTY-k, a ~ / .bash\_profile fájl nincs végrehajtva, de a ~ / .bashrc az.
- Nem interaktív shell esetében, azaz az egyik vagy mindkét stdin / stderr nem TTY, nem hajt végre konfigurációs szkriptet .
- A bejelentkezési héjban, kijelentkezéskor egy ~ / .bash\_logout fájlt futtatnak, ha van ilyen.
- A POSIX szerint stderr (és nem stdout ) az az adatfolyam, amely meghatározza, hogy a héj interaktív-e. Ha a stderr átirányításra kerül, akkor az nem interaktív shell, hacsak -i nincs megadva a a héjhívás. A stdout nem ugyanaz a hatása.
Válasz
Ez csak az én véleményem, de ha exit egy shell függvény összefüggésében (amely kilép az aktuális shell folyamatból) megegyezett egy return (amely visszatér a aktuális függvény), akkor nem írhatott kódot egy olyan shell függvénybe, amely kilép az aktuális szkriptből, amikor végzetes állapotot észlel a kód a függvénytörzsben. Gondoljon a futásidejű assert() (vagy ekvivalensek) strukturáltabb programozási nyelvű hívásokra.
Ehelyett csak annyit tehet, hogy hibakódot küld vissza a hívónak.
Igaz, a végzetes hibákból való hirtelen kilépés nem biztos, hogy a legjobb programozási stílus (a Subversion libsvn -ének egykor nagyon rossz hírneve volt: végzetes hibákat észleltek a a könyvtár kódja azt eredményezte, hogy a program hirtelen abbahagyta, így esélye sem volt a hívó kódnak, hogy értesítse a felhasználót, vagy megpróbáljon helyreállni a hibából).
Mindazonáltal az, hogy végzetes hibák észlelésekor hirtelen kiléphet meglehetősen praktikus a várt körülmények között működő megoldások kifejlesztésében – és a shell programozás (és így a GNU Bash programozás is) mindig a rövid gyakorlati megoldások a gyakori esetekhez, és nem összetett megoldások, amelyek gondosan kezelik az összes lehetséges adatot l eset (rengeteg más eszköz / nyelv létezik ehhez, legyen az C, Tcl, Perl, Python vagy akár PowerShell).
Ne feledje azt sem, hogy valószínűleg miért használ valaki Bourne shell szkriptet a az első hely a fent említett eszközök / nyelvek használata helyett azért van, mert az előbbi használatával meglehetősen könnyebb összerakni valamit, ami valóban hasznos munkát végez, mint az utóbbit – az a feltételezés volt egyszer, hogy a shell parancsfájlok lehetővé tették a felhasználók számára, hogy szinte ugyanazt a szintaxist használják, és eszközök, amelyeket minden nap interaktívan használtak, tehát olyasmit, amit már ismertek.
Ön azt kérdezte: A bash beépített return parancsa a következő: a shell működik, de miért nem elegendő az exit parancs a shell funkciókhoz?