¿Es esto un error en bash? `return` no sale de la función si se llama desde una tubería

Últimamente he tenido algunos problemas extraños con bash. Mientras intentaba simplificar mi script, se me ocurrió este pequeño fragmento de código:

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

returndebería haber salido de la función sin imprimir $?, ¿no? Bueno, luego verifiqué si puedo regresar solo de una tubería:

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

Lo mismo sucede sin un whilebucle:

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

¿Hay algo que me falta aquí? ¡Una búsqueda en Google no trajo nada sobre esto! Mi versión bash es la versión 4.2.37 (1) en Debian Wheezy.

Relacionado: /programming//a/7804208/4937930

No es un error que no pueda salir de un script o regresar de una función por exito returnen subcapas. Se ejecutan en otro proceso y no afectan el proceso principal.

Además de eso, supongo que está viendo comportamientos indocumentados de bash en (probablemente) especificaciones indefinidas. En una función, no se afirman errores returnen el nivel superior de los comandos de subshell y simplemente se comporta como exit.

En mi humilde opinión, es un error bash por el comportamiento inconsistente de returndepender de si la declaración principal está en una función o no.

#!/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 $?

Salida:

$ 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

No es un error bashsino su comportamiento documentado :

Cada comando en una tubería se ejecuta en su propia subshell

La returninstrucción es válida al estar dentro de una definición de función pero al estar también en una subshell, no afecta a su shell principal, por lo que la siguiente instrucción echo, se ejecuta independientemente. Sin embargo, es una construcción de shell no portátil ya que el estándar POSIX permite que los comandos que componen una tubería se ejecuten en un subshell (el predeterminado) o el superior (una extensión permitida).

Además, cada comando de una tubería de comandos múltiples está en un entorno de subshell; como extensión, sin embargo, cualquiera o todos los comandos en una tubería pueden ejecutarse en el entorno actual. Todos los demás comandos se ejecutarán en el entorno de shell actual.

Con suerte, puede decir bashque se comporte de la manera que espera con un par de opciones:

$ 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

Según la documentación de POSIX, el uso returnfuera de la función o el script de origen no está especificado . Entonces, depende de su shell para manejar.

El shell de SystemV informará un error, mientras que dentro ksh, returnfuera de la función o el script de origen se comporta como exit. La mayoría de los otros shells POSIX y schily's osh también se comportan así:

$ 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

kshy zshno salió porque la última parte de la tubería en estos shells se ejecutó en el shell actual en lugar del subshell. La declaración return afectó el entorno actual del shell que llamó a la función, ya que la función regresa inmediatamente sin imprimir nada.

En la sesión interactiva, bashsolo informe el error pero no finalizó el shell, schily's oshinformó el error y finalizó el shell:

$ 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

( zshen la sesión interactiva y la salida es terminal, no terminó bash, yashe schily's oshinformó el error pero no terminó el shell)

Creo que obtuvo el comportamiento esperado, en bash, cada comando en una tubería se ejecuta en una subshell. Puede ser usted mismo tratando de modificar una variable global de su función:

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

Por cierto, el retorno está funcionando pero regresa desde la subshell. De nuevo puedes comprobar que:

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

Producirá lo siguiente:

1
This should not be printed.

Entonces, la declaración de retorno salió correctamente de la subshell

.

La respuesta más general es que bash y algunos otros shells normalmente colocan todos los elementos de una tubería en procesos separados. Esto es razonable cuando la línea de comando es

programa 1 | programa 2 | programa 3

ya que los programas normalmente se ejecutan en procesos separados de todos modos (a menos que usted lo indique ) Pero puede ser una sorpresa paraexec program

comando 1 | comando 2 | comando 3

donde algunos o todos los comandos son comandos integrados. Los ejemplos triviales incluyen:

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

Un ejemplo un poco más realista es

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

donde todo while... do... el donebucle se coloca en un subproceso, por lo que sus cambios tno son visibles para el shell principal después de que finaliza el bucle. Y eso es exactamente lo que estás haciendo: conectando un whilebucle, haciendo que el bucle se ejecute como una subshell, y luego tratando de regresar de la subshell.