[BusyBox] Re: Bug Report:BB 1.00 sed

[Rob Landley]

On Tuesday 02 November 2004 06:41, Hiroshi Ito wrote:
> From: Rob Landley <rob at landley.net>
> Subject: Re: [BusyBox] Re: Bug Report:BB 1.00 sed
> Date: Tue, 2 Nov 2004 01:06:15 -0600
>
> > sed "" test /dev/null
> > cat test /dev/null | sed ""
> >
> > Then again, these two produce also different outputs (but the both
> > busybox and gnu produce the same two outputs), and it makes sense that
> > they do...
>
>   Yes, To tell the truth, I don't like this behavior.
>   I think this two example should produce a same output.
>   but nobody will listen and understand this claim.
>   ( and I can't say strongly, becouse I don't know exactly
>     how traditional sed was worked. )
>   So, I should understand GNU implementation, and follow
>   how GNU do it...

I understand your claim, but I disagree with it.  The whole "final newline is 
sometimes suppressed depending on whether the input behavior had one" is 
probably a technical violation of the sed spec, which I suspect says that 
whatever your input is the output of sed should have each line properly 
terminated with a newline.  (And if that didn't match the input, tough.)

The behavior I implemented in busybox was that if any input line didn't end 
with a newline (which can only happen at the end of an input stream but which 
isn't necessary the last of the input streams we're looking at), then we 
don't output one unless we need to insert one if necessary to keep it 
distinct from any later lines we print in the same batch (from a later input 
stream).

It turns out the behavior GNU is using is that if and only if the last line of 
all concatenated input streams doesn't have a newline, then it doesn't output 
a newline.

Both are either a technical violation of the spec, or taking liberties with 
undefined behavior.

> Mostly same problem are in sh,
>   # echo a b | (read a; echo $? $a)
>   0 a b
>   # echo -n a b | (read a; echo $? $a)
>   1 a b	    <- return value of read is depend on EOF.
>   #
>   this means "while read ...; do" is not enough to process whole of file.

That one I don't play with.

>   bash and GNU ash works same.

There's a GNU ash?

>   The line, whitch does not end with newline,
>   is undefined(=implimentation dependent) is enough.

What that really means is you're dealing with crummy input.

I can easily make a compile option so sed will ALWAYS put a newline on the 
end.  Probably make the code smaller.  Would that help?

Rob