Bästa svaret
Tack för A2A.
Jag tror att Anmol Vishwakarma har gett en utmärkt beskrivning av materia.
Bara för att se till att vi sätter saker i perspektiv:
- / etc / profile, ~ / .bash\_rc , och ~ / .bash\_profile, är alla filer och kallas c konfigurationsskript. De kan innehålla variabeldeklarationer, exportvariabler, kommandon som ska köras vid inloggning som e-post eller nyhetskontroll, inställning av bland annat. Typiska saker som användare gör är: lägga till lite dir till $ PATH, exportera någon variabel, ändra $ PS1, ställa in färger på skärmen, lägga till ett hälsningsmeddelande osv.
- Alla dessa filer, förutom / etc / profile, är som standard dolda, som betecknas med den ledande punkten (så det är inte bash\_profile men faktiskt .bash\_profile ).
- När du loggar in (antingen lokalt eller på distans) kallas detta ett inloggningsskal och behandlas lite lite annorlunda än normal skalanrop. I så fall körs / etc / profile -filen, om den finns, varefter antingen en ~ /.bash\_profile eller en ~ / .bashrc -fil körs i den ordningen.
- För ett interaktivt skal, dvs. den du kan interagera med, eftersom skalets stdin och stderr är båda TTYs, ~ / .bash\_profile filen körs inte, men ~ / .bashrc är.
- För ett icke-interaktivt skal, dvs. det med antingen en eller båda stdin / stderr inte är en TTY, körs inget konfigurationsskript .
- I ett inloggningsskal, vid utloggning, körs en ~ / .bash\_logout -fil, om den finns.
- Enligt POSIX, stderr (och inte stdout ) är strömmen som avgör om ett skal är interaktivt. Om stderr omdirigeras är det inte ett interaktivt skal, såvida inte -i anges i skalpåkallelsen. stdout har inte samma effekt.
Svar
Det är bara min åsikt, men om exit i samband med en skalfunktion (som avslutar den aktuella skalprocessen) var samma som en return (som återgår från nuvarande funktion), då kunde du inte skriva kod i en skalfunktion som avslutar det aktuella skriptet när ett dödligt tillstånd upptäcks av koden i funktionens kropp. Tänk på samtal till runtime assert() (eller motsvarigheter) på mer strukturerade programmeringsspråk.
Allt du kan göra istället är att returnera en felkod till den som ringer.
Det är sant att plötsligt avsluta på dödliga fel är definitivt inte den bästa programmeringsstilen (Subversions libsvn hade en gång ett mycket dåligt rykte på grund av detta: dödliga fel upptäcktes i bibliotekskoden resulterade i att programmet använde det slutade plötsligt och gav ingen chans att ringa koden för att meddela användaren eller för att försöka återhämta sig från felet).
Att kunna plötsligt avsluta när man upptäcker dödliga fel är dock ganska praktiskt för att utveckla lösningar som fungerar under de förväntade förhållandena – och skalprogrammering (och därmed GNU Bash-programmering också) har alltid handlat om att tillhandahålla korta praktiska lösningar för vanliga fall, och inte komplexa lösningar som noggrant hanterar alla möjliga specia I fall (det finns många andra verktyg / språk för det, vare sig det är C, Tcl, Perl, Python eller till och med PowerShell).
Observera också att den troliga anledningen till att någon använder Bourne-skalskript i Först och främst istället för att använda de ovan nämnda verktygen / språken beror det på att med det förra är det ganska lättare att sätta ihop något som verkligen fungerar bra än att använda det senare – antagandet en gång var att shell-skript tillät användare att använda nästan samma syntax och verktyg som de använde interaktivt varje dag, vilket var något de redan kände till.
Du frågade: Det inbyggda ”return” -kommandot i bash är för skalfunktionerna, men varför räcker inte kommandot exit för skalfunktioner?