NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/45955: sed(1) fails to append newline after 'c' command
The following reply was made to PR bin/45955; it has been noted by GNATS.
From: "Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: bin/45955: sed(1) fails to append newline after 'c' command
Date: Thu, 9 Feb 2012 16:08:56 +0400
My sed is very rusty, but I think you got the sequence of events
slighly wrong. I would consider "c" to be more like a shorthand for
"i" + "d", so 3) and 4) in your list never happen (like for "d").
The question is what happens at 2b) - and here the described effect
only manifests when the script is specified with -e or if the c
command is last in the file (-f) and the file has no final newline.
"a" and "i" behave the same as "c" here, btw.
Compare
$ cat pr45955.sed # without newline at the end of the file
c\
bar$ echo foo | sed -f pr45955.sed
bar$
vs.
$ cat pr45955.sed
c\
bar
$ echo foo | sed -f pr45955.sed
bar
$
For GNU sed output is "bar\n" for both scripts.
Of course, if "c" is not the last command in the file there's simply
no way to specify "text" without the final newline, so any knee jerk
objections (and, yes, it was mine too :) "how do you replace without a
newline?" are overruled.
So the observed effect is here because when a command line (-e) or the
last line of a script (-f) are processed and there's no final newline
and the line contains "text" for "a", "c" or "i" command, the newline
is not added to the "text".
I think it's a bug, but a bug in processing of script's source, not in
"c" command.
-uwe
Home |
Main Index |
Thread Index |
Old Index