From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <55945c6c91ffdd9cada6401af5f9ff08@krabbe.dyndns.org> To: <9fans@9fans.net> Date: Wed, 12 Aug 2015 13:35:36 +0200 From: Ingo Krabbe In-Reply-To: <20150812081302.GA886@polynum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] p9p sed vs linux sed Topicbox-Message-UUID: 66673f20-ead9-11e9-9d60-3106f5b1d025 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% And that is even consistent with (POSIX?) ed on linux systems or anywhere else. 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. 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. 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. If you seek for a sed like thing that does not work line oriented, use ssam, as sam and the streamed version ssam, process input in another way, that is not line oriented. cheers ingo > On Wed, Aug 12, 2015 at 09:57:18AM +0200, Rudolf Sykora wrote: >> On 12 August 2015 at 09:48, Ingo Krabbe wrote: >> >> > Actually sed is a line based command and should add a newline, imho. >> >> I don't think it should add anything. For itself it should be able to count >> newlines (because of the possible use of addresses), but otherwise it >> should not do anything extra (it should be possible to pipe through >> two seds, for instance). >>