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