On Mon, 14 Jun 2010, Jeremy Olexa wrote: > On 06/14/2010 06:18 PM, Mike Miller wrote: > >> Have you run into this problem before? I have one script calling a >> second script. The second script contains this code: >> >> if [ -e index.html ]; then >> echo -e "\nCtrl-c to preserve old index.html and terminate processing\n" >> echo "enter 'y' to delete index.html, or 'n' to retain the current index.html" >> rm -i index.html >> fi >> >> >> When we get to that section, if index.html exists, this is what we see >> on the screen (I entered the 'y' that's on a line by itself): >> >> Ctrl-c to preserve old index.html and terminate processing >> >> enter 'y' to delete index.html, or 'n' to retain the current index.html >> y >> rm: remove regular empty file `index.html'? >> >> >> In other words, it does not show the prompt from "rm -i" until after >> the response has been entered. Any ideas? I think it has something to >> do with the fact that the script is called by another script. If I >> call the script directly from the command line, it behaves just fine. >> It would make more sense to me if I never saw the prompt, but it does >> appear, just a little too late. > > I'm fairly certain it is because echo is printing to stdout and rm -i is > stderr. > > Try "rm -i index.html 2>&1" (redirect stderr to stdout) in your script > to see if that changes anything. Or, "echo <blah> 1>&2 " to redirect > stdout to stderr. > > I could be wrong here, but it is a hunch. Some of you will probably want to read the end of this (last three commands and ensuing two sentences) and skip the rest... You are definitely close to getting the answer. I also was thinking it had to do with stderr, but I couldn't figure it out. There was one really important thing that I hadn't said, but only because I had forgotten about it (that's what I get for using up-arrow so many times in a row). That is, I was using some redirection on the command line. Without that, I don't have the problem. Here's what it looked like: script --options 2>&1 | grep -vE '^Xlib' That somehow blocks the "rm: remove" prompt until after I respond to it, but this works fine: script --options 2>&1 The way I was seeing it, the use of "2>&1" redirects stderr to stdout so that the grep command can operate on what previously was stderr. It seems to work in that I don't get the bothersome Xlib messages, which look like this by the way: Xlib: extension "RANDR" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "RANDR" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Pretty much every program that uses X causes those bothersome messages, and perhaps many others, to fill up my terminal, so I am constantly doing this for X programs... program &>/dev/null & ...when I want to be doing this: program & I think it has something to do with the video driver and maybe the fact that I'm doing everything via VNC (over SSH). Anyway, I remain perplexed about why my plan isn't working the way I want for this case. I don't see why grep should block the stderr output from rm, but someone here might understand it. 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. Best, Mike