Najlepsza odpowiedź
Dzięki za A2A.
Uważam, że Anmol Vishwakarma dał doskonały opis sprawy.
Aby upewnić się, że spojrzymy na sprawy z odpowiedniej perspektywy:
- / etc / profile, ~ / .bash\_rc , i ~ / .bash\_profile to wszystkie pliki nazywane skryptami c konfiguracyjnymi. Mogą zawierać deklaracje zmiennych, zmienne eksportu, polecenia do wykonania przy logowaniu, takie jak sprawdzanie poczty lub grup dyskusyjnych, między innymi ustawienie umask. Typowe rzeczy, które użytkownicy robią to: dodawanie katalogu do $ PATH, eksportowanie jakiejś zmiennej, zmiana $ PS1, ustawianie kolorów wyświetlacza, dodawanie powitania itp.
- Wszystkie te pliki z wyjątkiem / etc / profile są domyślnie ukryte, co jest oznaczone wiodącą kropką (więc nie jest to bash\_profile , ale właściwie .bash\_profile ).
- Podczas logowania (lokalnie lub zdalnie) jest to tzw. powłoka logowania i jest traktowane nieco różni się od zwykłego wywołania powłoki. W takim przypadku plik / etc / profile , jeśli istnieje, jest wykonywany, po czym ~ /.bash\_profile lub plik ~ / .bashrc jest wykonywany w tej kolejności.
- W przypadku powłoki interaktywnej, tj. ten, z którym możesz wchodzić w interakcje, ponieważ stdin i stderr powłoki to TTY, plik ~ / .bash\_profile nie jest wykonywany, ale ~ / .bashrc jest.
- W przypadku powłoki nieinteraktywnej, tj. ta z jednym lub dwoma stdin / stderr nie jest TTY, żaden skrypt konfiguracyjny nie jest wykonywany .
- W powłoce logowania, podczas wylogowywania, wykonywany jest plik ~ / .bash\_logout , jeśli jest obecny.
- Zgodnie z POSIX, stderr (a nie stdout ) to strumień, który określa, czy powłoka jest interaktywna. Jeśli stderr zostanie przekierowany, nie jest to powłoka interaktywna, chyba że -i jest określone w wywołanie powłoki. standardowe wyjście nie daje takiego samego efektu.
Odpowiedź
To tylko moja opinia, ale jeśli exit w kontekście funkcji powłoki (która kończy bieżący proces powłoki) było takie samo jak return (który zwraca z current function), wówczas nie można było napisać kodu w funkcji powłoki, która zamyka bieżący skrypt, gdy kod w treści funkcji wykryje stan krytyczny. Pomyśl o wywołaniach środowiska wykonawczego assert() (lub odpowiedników) w bardziej ustrukturyzowanych językach programowania.
Zamiast tego wystarczy zwrócić kod błędu do dzwoniącego.
Prawdą jest, że nagłe zakończenie działania po błędach krytycznych zdecydowanie nie jest najlepszym stylem programowania (libsvn Subversion miał kiedyś bardzo złą reputację z tego powodu: krytyczne błędy wykryte w kod biblioteki spowodował, że program wykorzystujący ją nagle zakończył pracę, nie dając wywołującemu kodowi szansy na powiadomienie użytkownika lub próbę odzyskania sprawności po błędzie).
Niemniej jednak, możliwość gwałtownego zakończenia podczas wykrywania błędów krytycznych jest dość praktyczne w tworzeniu rozwiązań, które działają w oczekiwanych warunkach – a programowanie powłoki (a tym samym również programowanie GNU Bash) zawsze polegało na zapewnieniu krótkie praktyczne rozwiązania dla typowych przypadków, a nie skomplikowane rozwiązania ostrożnie obsługujące każdą możliwą specyfikę l (istnieje wiele innych narzędzi / języków do tego celu, czy to C, Tcl, Perl, Python, czy nawet PowerShell).
Należy również zauważyć, że prawdopodobny powód, dla którego ktoś używa skryptów powłoki Bourne w po pierwsze, zamiast korzystać z wyżej wymienionych narzędzi / języków, jest to, że używając pierwszego, znacznie łatwiej jest złożyć coś, co faktycznie wykonuje użyteczną pracę, niż używać drugiego – założono kiedyś, że skrypty powłoki pozwalają użytkownikom używać prawie tej samej składni i narzędzia, których używali interaktywnie każdego dnia, a więc coś, co już znali.
Zapytałeś: Wbudowane polecenie „return” w bash służy do funkcje powłoki, ale dlaczego polecenie exit nie jest wystarczające dla funkcji powłoki?