builtin echo command redirection misbehaves in detached scripts when terminal is closed
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 uname output: Linux akula 2.6.17.7 #4 Sat Sep 8 23:10:46 CEST 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: With Unix-98 ptys, the builtin echo command gets executed even when writing to stdout or redirecting to stderr fails, and the output gets written to the wrong file descriptor if any other redirection is used in the script. Repeat-By: For example, with the following script: while [ 1 ];do echo Test1 echo Test2 >> file.txt sleep 1 done As expected, when this script is run in the background (&), the console slowly fills with "Test1" lines, and the file.txt file slowly fills with "Test2" lines. Now exit the shell leaving the script running (don't simply close the xterm, that'd kill the script. Type "exit"). Since the terminal has closed, stdout is closed, so "echo Test1" should fail. It doesn't, instead it writes "Test1" lines into whatever open file descriptor it can find. In this case, file.txt starts filling up with Test2 Test1 Test2 Test1 ... This does not happen with BSD-style ptys, because apparently when the terminal is closed, the tty seen by the detached bash script stays intact, and whatever is written to the now-closed terminal is simply discarded by the kernel, so the script keeps seeing open stdout and stderr file descriptors. In the case of Unix-98 ptys, this bug happens because the tty file descriptors the bash script uses are really closed This also does not happen with an external echo command: with /bin/echo, the redirection fails and the command is not executed, as expected.
Re: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Andreas Schwab wrote: I get this: $ bash -c 'trap "" PIPE; sleep 1; echo a; echo b > a' | : bash: line 0: echo: write error: Broken pipe and the file contains only one line. Andreas. I did more tests, and this is what I came up with: - akula, my bleeding edge box, is a Debian-unstable box upgraded yesterday sept 8, 2007. It runs linux-2.6.17.7, libc6-2.6.1 - kilo, my most up-to-date box where bash still seems to behave properly with regard to that problem, is also a Debian-unstable box, upgraded on may 1st, 2007. It runs linux2.6.18, libc6-2.5 On both boxes, I tried Stephane's test line with bash-3.1.17 and bash-2.05b: On both boxes, with bash-3.1.17, I get the "bash: line 0: echo: write error: Broken pipe" message, and no error message with bash-2.05b. On akula, both versions of bash generate a file with 2 lines. On kilo, both version of bash generate a correct file with 1 line. I hope this helps. I'll keep the kilo box in "working bash state" if anybody wants ssh access to it to test further.
Re: builtin echo command redirection misbehaves in detached scripts when terminal is closed
The change is far from trivial or harmless, if it was intended. I had to rebuild a custom server I run in a hurry because it was flooding an IRC channel with log lines a backend bash script sent to stderr. And I can think of plenty of ways to trash files with this bug. Anyway, thanks a lot Stéphane and Andreas for testing this! Stephane Chazelas wrote: Now, I'm not sure if we can say that the new glibc behavior observed is bogus (other than it's different from the behavior observed in all the libcs I tried with). It is not a harmless change, for sure as it seems to have broken at least bash, zsh and possibly ksh93. Dmitry, you may find that whole thread at: http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/e311bdd4f945a21e/621b7189217760f1 Best regards, Stéphane
