Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux rover 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 GNU/Linux Machine Type: i486-pc-linux-gnu
Bash Version: 4.1 Patch Level: 5 Release Status: release Description: I don't believe that the following behaviour is sensible or matches the standard/documentation: $ f () { { echo 1 ; echo 2 ; } | while read line ; do echo $line ; return 0 ; done ; echo foo ; return 1 ; } $ f 1 foo $ echo $? 1 I expect f to return 0 from within the loop because a function is executing. I know the return 0 is in a subprocess at the end of a pipeline... but that whole pipeline is running within a function. Naturally, the above is a contrived, minimal example. In general I expect to be able to pipe the output of a command into a loop and have the loop read lines until some condition occurs, at which point my function returns. This could obviously be done using a out=$(cmd) subprocess... except in the case where cmd can block before producing all of its output. Hence, the above seems convenient. Repeat-By: See above. Fix: I'd expect a fix to be tricky... which probably explains the current behaviour. ;-) peace & happiness, martin