From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <55945c6c91ffdd9cada6401af5f9ff08@krabbe.dyndns.org>
References: <20150812081302.GA886@polynum.com>
	<55945c6c91ffdd9cada6401af5f9ff08@krabbe.dyndns.org>
Date: Wed, 12 Aug 2015 14:39:29 +0200
Message-ID: <CAOEdRO2soYHKPwoHWvgC1mXauiDwiX04LF575SXARUVCCa4JgQ@mail.gmail.com>
From: Rudolf Sykora <rudolf.sykora@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [9fans] p9p sed vs linux sed
Topicbox-Message-UUID: 666bbcee-ead9-11e9-9d60-3106f5b1d025

On 12 August 2015 at 13:35, Ingo Krabbe <ikrabbe.ask@gmail.com> wrote:
> Luckily plan9 is not POSIX and actually sed does not really add a
> newline character, it just puts a newline to the end of each pattern
> buffer, that is done line-wise anyway. Also sed's little brother ed
> behaves the same, which makes the behaviour even more convenient
>
> term% echo -n 'abc' > inp
> term% cat inp
> abcterm% ed inp
> '\n' appended
> 4
> wq
> 4
> term%

Ed most probably does this in order to be usable, in the first
place (so that your commands do not mix with text).
(And it makes you quite aware of this action.)


> There is a very good reason to do so: The rule just applies to the
> end-of-input! So when you output a pattern from the sed buffer, you
> would need to check each time if we are at the end or not and add the
> newline or not, if it has been there or not.

this is what linux' sed seems to do.


> All those branches for
> just one character at the end of the input that can be easily removed
> if you really don't want it.

I don't think so. It may happen you do not know in advance if you want
it or not. By running p9p sed you loose information; that's generally a
bad thing.


> So for simplicity there are very good reasons to state that any output
> from sed will end in a newline, even if the input doesn't.

this, in my opinion, only complicates things.

Thanks
Ruda