<br><br><div class="gmail_quote">On Tue, Jun 15, 2010 at 12:49 AM, Mike Miller <span dir="ltr"><<a href="mailto:mbmiller%2Bl@gmail.com">mbmiller+l@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tue, 15 Jun 2010, Mike Miller wrote:<br>
<br>
> Here's something safe and easy that anyone can try at home:<br>
><br>
> ( touch foo ; echo bar ; rm -i foo ) 2>&1<br>
><br>
> ( touch foo ; echo bar ; rm -i foo ) 2>&1 | grep -v bar<br>
><br>
> ( touch foo ; echo bar ; rm -i foo ) 2>&1 | grep -v baz<br>
><br>
> See what I mean? Apparently, rm can't send its stderr until the grep<br>
> command has completed, so it just sits there waiting for input.<br>
<br>
<br>
</div>If I use cat instead of grep, it's fine. It has something to do with the<br>
newline: rm -i doesn't send a newline with the prompt. Compare the<br>
behavior of these:<br></blockquote><div><br>When doing I/O, remember that underneath the <br>printf's and readln's are "read" and "write" system calls, and<br>that these work against buffers. Output buffers don't flush <br>
until they see a newline, EOF marker, or the file handle <br>is closed (causing the OS to flush the buffer <br>as it is deallocated), or the filehandle is the argument of a <br>system call to force a flush (flush()?). Correspondingly, a flushed <br>
buffer linked to a file on disk is in turn not yet safely written - <br>sync or fsync commands are the safe bet there. <br><br>A lot of times you will see buffers flush as a program exits <br>because many programmers don't explicitly close their <br>
file handles and so it's the process-cleanup process that <br>flushes buffers prior to deallocating the filehandles and - if <br>necessary - the buffers themselves. <br><br>I believe there are ways to configure a filehandle to immediately <br>
flush-through everything that is written. Of course - that leads <br>to many more interrupts and is not as efficient, but it is possible. <br>I'm not sure how to do that though - I haven't had to deal with <br>I/O at that level for a long time. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Maybe we would be better off if the prompt from "rm -i" sent a newline.<br>
On the other hand, maybe I should just never use "rm -i" in a script.<br>
There has to be a better way.<br>
<div><div></div><br></div></blockquote><div><br>I would not use rm -i in a script, ever, mainly just for style reasons. For <br>example, it's possible on some unix implementations your script would <br>work as expected because that implementation of rm does send a new-line, <br>
but then when moving the script somewhere else - whoah - gnu's rm <br>doesn't send a new-line - whoops! And maybe some rm's write to stdout, <br>and some to stderr. I'd wrap that rm with my own <br>I/O management code that is (hopefully) more portable and trustworthy. <br>
<br>-Rob <br></div></div>