[9fans] p9p sed vs linux sed

[9fans] p9p sed vs linux sed

[Rudolf Sykora]

Hello,

is this as expected?

perseus=; echo -n aaa | 9 sed 's/^/</'
<aaa
perseus=; echo -n aaa | sed 's/^/</'
<aaaperseus=;


For me the linux sed does what I expect,
but not the p9p one (it adds a newline). Why?

Thanks!
Ruda

Re: [9fans] p9p sed vs linux sed

[Ingo Krabbe]

You mean perseus=; is your prompt? Strange.

Actually sed is a line based command and should add a newline, imho. You can simply use tr -d '\n'.

There are several quoting differences between plan9 sed and linux sed and I think the \+ operator doesn't work anyway in linux sed, but I might be wrong with this statement.

cheers,
ingo

> Hello,
>
> is this as expected?
>
> perseus=; echo -n aaa | 9 sed 's/^/</' |tr -d '\n'
> <aaa
> perseus=; echo -n aaa | sed 's/^/</'
> <aaaperseus=;
>
>
> For me the linux sed does what I expect,
> but not the p9p one (it adds a newline). Why?
>
> Thanks!
> Ruda

Re: [9fans] p9p sed vs linux sed

[Rudolf Sykora]

On 12 August 2015 at 09:48, Ingo Krabbe <ikrabbe.ask@gmail.com> wrote:
> You mean perseus=; is your prompt? Strange.

Yes. perseus=; is the prompt.

> 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).

Ruda

Re: [9fans] p9p sed vs linux sed

[Ingo Krabbe]

> You mean perseus=; is your prompt? Strange.
>
> Actually sed is a line based command and should add a newline, imho. You can simply use tr -d '\n'.
>
> There are several quoting differences between plan9 sed and linux sed and I think the \+ operator doesn't work anyway in linux sed, but I might be wrong with this statement.

ok, I remember that I had problems with the + operator with some linux command, but those seem to be gone on my system.

the plan9 version of tr does not use '\n' of course but '\12' or '\x0a'.

Re: [9fans] p9p sed vs linux sed

[tlaronde]

On Wed, Aug 12, 2015 at 09:57:18AM +0200, Rudolf Sykora wrote:
> On 12 August 2015 at 09:48, Ingo Krabbe <ikrabbe.ask@gmail.com> 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).
>

>From the POSIX description (used here as some reference), when a
line is entered in the pattern space, the trailing new line is
discarded. When the pattern space is written to stdout it seems
that implicitely the new line is restored---the POSIX description
says that the input shall be a text file; and ISTR that with an
editor, a newline is entered to the last line because a text file
is considered to be an array of newline terminated lines.

This means that it is a grey zone and depends on things that are not all
explicitely stated and that the p9 sed(1) is not, from the/some
specification, at fault.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] p9p sed vs linux sed

[Rudolf Sykora]

> From the POSIX description (used here as some reference), when a
> line is entered in the pattern space, the trailing new line is
> discarded. When the pattern space is written to stdout it seems
> that implicitely the new line is restored---the POSIX description
> says that the input shall be a text file; and ISTR that with an
> editor, a newline is entered to the last line because a text file
> is considered to be an array of newline terminated lines.
>
> This means that it is a grey zone and depends on things that are not all
> explicitely stated and that the p9 sed(1) is not, from the/some
> specification, at fault.

Thanks for some explanation!
I now understand a bit more.
It's a pity, anyhow.

Ruda

Re: [9fans] p9p sed vs linux sed

[Ingo Krabbe]

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 <ikrabbe.ask@gmail.com> 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).
>>

Re: [9fans] p9p sed vs linux sed

[Rudolf Sykora]

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

Re: [9fans] p9p sed vs linux sed

[lucio]

> this, in my opinion, only complicates things.

You can't write a file in vi that does not end in a newline.  I never
found that problematic, even though sometimes one might wish to be
able to overrule vi.

So, I vote that text handling utilities should deal with all lines in
text files uniformly,even the last one.

Lucio.

Re: [9fans] p9p sed vs linux sed

[Rudolf Sykora]

On 12 August 2015 at 15:47,  <lucio@proxima.alt.za> wrote:
> You can't write a file in vi that does not end in a newline.

You, however, can do it pretty easily with cat.
(Sam asks you if you mean it, acme just does it.)

> So, I vote that text handling utilities should deal with all lines in
> text files uniformly,even the last one.

I encountered the problem when I selected a couple of words in acme
which I wanted to bracket with sed with something like

| sed 's/^/</' | sed 's/$/>/'

and suddenly you see...

On the other hand, as you say, it's a matter of taste.
(If the behaviour is not prescribed.)

R Sykora

Re: [9fans] p9p sed vs linux sed

[Ingo Krabbe]

> | sed 's/^/</' | sed 's/$/>/'
>

Why would you pipe text data in acme through sed and not use

	Edit x/^.*$/s/.*/<&>/

?

Re: [9fans] p9p sed vs linux sed

[Alexander Kapshuk]

On Wed, Aug 12, 2015 at 10:39 AM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
> Hello,
>
> is this as expected?
>
> perseus=; echo -n aaa | 9 sed 's/^/</'
> <aaa
> perseus=; echo -n aaa | sed 's/^/</'
> <aaaperseus=;
>
>
> For me the linux sed does what I expect,
> but not the p9p one (it adds a newline). Why?
>
> Thanks!
> Ruda
>

In case you were still wondering about the 'why' of the behaviour of
sed you encountered. See below.

P9p sed
-----------
/usr/local/plan9/src/cmd/sed.c:1316,1324
void
putline(Biobuf *bp, Rune *buf, int n)
{
    while (n--)
        Bputrune(bp, *buf++);
    Bputc(bp, '\n');
    if(lflag)
        Bflush(bp);
}

Plan9 sed
-------------
/sys/src/cmd/sed.c:1315,1321
void
putline(Biobuf *bp, Rune *buf, int n)
{
       while (n--)
               Bputrune(bp, *buf++);
       Bputc(bp, '\n');
 }

Modified local copy
--------------------------
/usr/$user/src/nsed.c:1315,1321
void
putline(Biobuf *bp, Rune *buf, int n)
{
        while (n--)
                Bputrune(bp, *buf++);
        /* Bputc(bp, '\n'); */
}

term% echo -n aaa | sed 's/^/</'
<aaa
term% echo -n aaa | nsed 's/^/</'
<aaaterm%

Re: [9fans] p9p sed vs linux sed

[erik quanstrom]

i think the change doesn't work for any multi-line file:

; cp /sys/src/cmd/sed.c /tmp/notsed.c
; cd /tmp
; ed notsed.c
; ed notsed.c
27827
putline(Biobuf *bp, Rune *buf, int n)
+4
	ebputc(bp, '\n');
d
w
27808
q
; tmk notsed.c
6c -FVTw notsed.c
6l -o 6.notsed notsed.6
; ; {echo a ; echo b} | 6.notsed 's/./.☺/g'
.☺.☺; 

- erik