Czy to błąd w bash? `return` nie wychodzi z funkcji, jeśli jest wywoływany z potoku

Ostatnio mam dziwne problemy z bash. Próbując uprościć mój skrypt, wymyśliłem ten mały fragment kodu:

$ o(){ echo | while read -r; do return 0; done; echo $?;}; o
0
$ o(){ echo | while read -r; do return 1; done; echo $?;}; o
1

returnpowinien był wyjść z funkcji bez drukowania $?, prawda? Cóż, wtedy sprawdziłem, czy mogę sam wrócić z rury:

$ echo | while read -r; do return 1; done
bash: return: can only `return' from a function or sourced script

To samo dzieje się bez whilepętli:

$ foo(){ : | return 1; echo "This should not be printed.";}
$ foo
This should not be printed.

Czy czegoś tu brakuje? Wyszukiwarka Google nic nie przyniosła! Moja wersja bash to 4.2.37 (1) - wydanie na Debian Wheezy.

Powiązane: /programming//a/7804208/4937930

To nie jest błąd, że nie można wyjść ze skryptu lub powrócić z funkcji przez exitlub returnw podpowłoce. Są one wykonywane w innym procesie i nie wpływają na proces główny.

Poza tym, przypuszczam, że widzisz nieudokumentowane zachowania bash na (prawdopodobnie) nieokreślonej specyfikacji. W funkcji nie są zgłaszane żadne błędy returnna najwyższym poziomie poleceń podpowłoki i po prostu zachowuje się jak exit.

IMHO jest błędem bashowym za niespójne zachowanie polegające returnna tym, czy główna instrukcja jest w funkcji, czy nie.

#!/bin/bash

o() {
    # Runtime error, but no errors are asserted,
    # each $? is set to the return code.
    echo | return 10
    echo $?
    (return 11)
    echo $?

    # Valid, each $? is set to the exit code.
    echo | exit 12
    echo $?
    (exit 13)
    echo $?
}
o

# Runtime errors are asserted, each $? is set to 1.
echo | return 20
echo $?
(return 21)
echo $?

# Valid, each $? is set to the exit code.
echo | exit 22
echo $?
(exit 23)
echo $?

Wynik:

$ bash script.sh 
10
11
12
13
script.sh: line 20: return: can only `return' from a function or sourced script
1
script.sh: line 22: return: can only `return' from a function or sourced script
1
22
23

To nie jest błąd, bashale jego udokumentowane zachowanie :

Każde polecenie w potoku jest wykonywane we własnej podpowłoce

returnInstrukcja jest ważna istota wewnątrz definicji funkcji, ale jest w podpowłoce, jak również, że nie ma wpływu na jego powłoki macierzystej więc następnej instrukcji, echojest realizowane niezależnie. Jest to jednak nieprzenośna konstrukcja powłoki, ponieważ standard POSIX pozwala na wykonywanie poleceń tworzących potok w podpowłoce (domyślnie) lub w górnej (dozwolone rozszerzenie).

Ponadto każde polecenie potoku z wieloma poleceniami znajduje się w środowisku podpowłoki; jednak jako rozszerzenie dowolne lub wszystkie polecenia w potoku mogą być wykonywane w bieżącym środowisku. Wszystkie pozostałe polecenia będą wykonywane w bieżącym środowisku powłoki.

Mamy nadzieję, że możesz powiedzieć, bashaby zachowywać się tak, jak oczekujesz, za pomocą kilku opcji:

$ set +m # disable job control
$ shopt -s lastpipe # do not run the last command of a pipeline a subshell 
$ o(){ echo | while read -r; do return 0; done; echo $?;}
$ o
$          <- nothing is printed here

Zgodnie z dokumentacją POSIX, używanie returnpoza funkcją lub skryptem źródłowym jest nieokreślone . To zależy od twojej powłoki do obsługi.

Powłoka SystemV zgłosi błąd, podczas gdy wewnątrz ksh, returnpoza funkcją lub skryptem źródłowym zachowują się jak exit. Większość innych powłok POSIX i osh Schily'ego zachowuje się tak:

$ for s in /bin/*sh /opt/schily/bin/osh; do
  printf '<%s>\n' $s
  $s -c '
    o(){ echo | while read l; do return 0; done; echo $?;}; o
  '
done
</bin/bash>
0
</bin/dash>
0
</bin/ksh>
</bin/lksh>
0
</bin/mksh>
0
</bin/pdksh>
0
</bin/posh>
0
</bin/sh>
0
</bin/yash>
0
</bin/zsh>
</opt/schily/bin/osh>
0

kshi zshnie wyprowadzał danych, ponieważ ostatnia część potoku w tych powłokach została wykonana w bieżącej powłoce zamiast podpowłoki. Instrukcja return wpłynęła na bieżące środowisko powłoki, które wywołało funkcję, powoduje natychmiastowe zwrócenie funkcji bez drukowania niczego.

W sesji interaktywnej bashzgłoś tylko błąd, ale nie zakończył powłoki, schily's oshzgłosił błąd i zakończył działanie powłoki:

$ for s in /bin/*sh; do printf '<%s>\n' $s; $s -ci 'return 1; echo 1'; done
</bin/bash>
bash: return: can only `return' from a function or sourced script
1
</bin/dash>
</bin/ksh>
</bin/lksh>
</bin/mksh>
</bin/pdksh>
</bin/posh>
</bin/sh>
</bin/yash>
</bin/zsh>
</opt/schily/bin/osh>
$ cannot return when not in function

( zshW sesji interaktywnej i wyjście to zrób terminal nie rozwiązana bash, yashi schily's oshzgłosił błąd, ale nie zakończyć powłoki)

Myślę, że masz oczekiwane zachowanie, w skrócie, każde polecenie w potoku jest wykonywane w podpowłoce. Możesz przekonać się, próbując zmodyfikować zmienną globalną swojej funkcji:

foo(){ x=42; : | x=3; echo "x==$x";}

Nawiasem mówiąc, powrót działa, ale wraca z podpowłoki. Ponownie możesz sprawdzić, czy:

foo(){ : | return 1; echo$?; echo "This should not be printed.";}

Wyprowadzi następujące:

1
This should not be printed.

Tak więc instrukcja return poprawnie opuściła podpowłokę

.

Bardziej ogólną odpowiedzią jest to, że bash i niektóre inne powłoki zwykle umieszczają wszystkie elementy potoku w osobnych procesach. Jest to uzasadnione, gdy wiersz poleceń to

program 1 | program 2 | program 3

ponieważ programy i tak są zwykle uruchamiane w oddzielnych procesach (chyba że mówisz ). Ale może to być zaskoczeniemexec program

polecenie 1 | polecenie 2 | polecenie 3

gdzie niektóre lub wszystkie polecenia są wbudowanymi poleceniami. Trywialne przykłady obejmują:

$ a=0
$ echo | a=1
$ echo "$a"
0
$ cd /
$ echo | cd /tmp
$ pwd
/

Nieco bardziej realistycznym przykładem jest

$ t=0
$ ps | while read pid rest_of_line
> do
>     : $((t+=pid))
> done
$ echo "$t"
0

gdzie cała while... do... donepętla wkłada się podproces, a więc jego zmian tnie są widoczne na głównej powłoce po zakończeniu pętli. I to jest dokładnie to, co robisz - pipowanie w whilepętli, powodowanie, że pętla działa jako podpowłoka, a następnie próba powrotu z podpowłoki.