Paolo Bonzini @ Fri, Apr 11, 2008 at 8:06 AM: > > 'if EOF || Error' or 'if ! read-is-OK' > > > > Latter applies for ordinary files also, no? No need of look ahead. > > > > This is the next-to-last line, not the last line. sed does test for it, > but because the result would be off-by-one, it has to look ahead one line.
Please clarify. "a '$' character that addresses the last line of input" http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html Is it was about how you do recognize last line before script gets to the end, i.e. '$' is next-to-last read() without EOF? If i use '$', i don't care about if another read() is done before current line is processed and script reruns. I want last line, whatever it is. In the corner case if the line was read and then network connection was dropped, hard drive failed or anything like that so one line is buffered, then this case of talking zombies is *not* a misbehaviour (see below). > > in interactive or line-by-line example shown, it's buggy. > > > > No. sed is not meant for "interactive or line-by-line" usage. What > matters is only the output. That may be, you never know, unless bug is documented as feature. But let's look at this from general POV. `sed` read lines and applies whole script to the line, i.e. line-by-line. What is done now is not performing this in reported case. Line isn't processed and printed. -- sed 'sed && sh + olecom = love' << '' -o--=O`C #oo'L O <___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
