On Tue, 15 Jun 2010, Mike Miller wrote: > Here's something safe and easy that anyone can try at home: > > ( touch foo ; echo bar ; rm -i foo ) 2>&1 > > ( touch foo ; echo bar ; rm -i foo ) 2>&1 | grep -v bar > > ( touch foo ; echo bar ; rm -i foo ) 2>&1 | grep -v baz > > See what I mean? Apparently, rm can't send its stderr until the grep > command has completed, so it just sits there waiting for input. If I use cat instead of grep, it's fine. It has something to do with the newline: rm -i doesn't send a newline with the prompt. Compare the behavior of these: ( touch foo ; echo bar 2>&1 ; rm -i foo 2>&1 ) | grep -E '.' ( touch foo ; echo bar | tr -d '\n' 2>&1 ; rm -i foo 2>&1 ) | grep -E '.' The "bar" is inhibited (somehow by removal of the newline) from appearing in the second command until after the response to the prompt, but it appears before the response to the prompt in the first command. More (the "y" is my input): $ ( touch foo ; echo bar ; rm -i foo ) 2>&1 | perl -pe 's/\? /? \n/' | grep -E '.' y bar rm: remove regular empty file `foo'? $ ( touch foo ; echo bar ; rm -i foo ) 2>&1 | grep -E '.' bar y rm: remove regular empty file `foo'? Maybe we would be better off if the prompt from "rm -i" sent a newline. On the other hand, maybe I should just never use "rm -i" in a script. There has to be a better way. Best, Mike