Re: sed : * final newline

[Stepan Kasal]

Hello,

On Tue, Jul 08, 2003 at 09:05:16AM +0200, Bonzini wrote:
> Yes, I know this.  The problem is that this does not affect only `sed :'
> but also `sed 10,$!d' and the like.

this one is OK: remove the first 9 lines, preserving everything else.
If the last line did not end with newline, the last line of the output
looks the same way.

> > This behaviour also violates POSIX, as it clearly states that:
> > "Whenever the pattern space is written to standard output or a named
> > file, sed shall immediately follow it with a <newline>."
> 
> No, POSIX expects that each line of pattern space is ended by a newline.  
> Otherwise
> behavior is undefined: HP/UX ignores the line, Solaris appends a new-line etc.

OK.  I'd still prefer to append newline at the no matter what the input
looked like, ie. the Solaris way.
I think this is the cleanest way---it has only one drawback, which can be
easily expressed: ``if the input file doesn't end with newline, a newline
will be appended.
You can invent some options to have a way to preserve the contents of such
weird files.

> The best would be to turn the flag into a three-state: put new-line after 
> (standard),
> no new-line, put new-line before (after a line without a new-line has been 
> printed).

Well, I do aggree that this is solution for my problem with " sed -n 'p;p' " .

But the original problem was that when you have 259 files, each contains one
word and no newline, then `sed : * | wc -l' outputs 258, which looks strange.

What about at least turning this feature off whenever the number of input
files is > 1 ?

I aggree that the three-state solution is right, unless you accept my
proposal to go the Solaris way.

Have a nice day,
        Stepan