Subject: bug#40242: closed (Re: bug#40242: n as delimiter alias)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 24 Oct 2022 06:26:02 +0000

Your bug report

#40242: n as delimiter alias

which was filed against the sed package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
40242: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40242
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#40242: n as delimiter alias
From: Jim Meyering <[email-masked]>
To: Eric Blake <[email-masked]>
Cc: [email-masked], Assaf Gordon <[email-masked]>,Oğuz <[email-masked]>
Date: Sun, 23 Oct 2022 23:25:05 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On Tue, Mar 31, 2020 at 6:36 AM Eric Blake <[email-masked]> wrote:
> On 3/31/20 2:00 AM, Oğuz wrote:
> > Thanks for the reply. This might not be a bug though; I sent a similar mail
> > (https://www.mail-archive.com/[email-masked]/msg05881.html)
> > to Austin Group mailing list asking what's the expected behavior in this
> > case, and I was told (
> > https://www.mail-archive.com/[email-masked]/msg05891.html)
> > both behaviors -yielding n or empty line- are correct and standard should
> > *probably* be amended to explicitly state that this is unspecified. And
> > apparently (
> > https://www.mail-archive.com/[email-masked]/msg05893.html)
> > some other UNIXes adopted the same practice as GNU sed (or vice versa, I
> > don't know which one is older).
>
> The POSIX folks will probably declare that use of a \X sequence (for
> arbitrary X; 'n', 't', '1', and probably others all fit this category)
> inside a regex delimited by X is unspecified behavior.  But that still
> doesn't stop us from fixing GNU set to at least be consistent - we
> should either blindly declare that \X represents the special meaning of
> X when such a meaning is present regardless of X also being the regex
> delimiter (our current \n behavior - no way to represent the delimiter
> as a literal match), or that use of X as a delimiter renders the special
> meaning of \X useless for that regex (our \t behavior - no way to
> represent the special behavior as part of the match).  My personal
> preference is making things consistent to our \t behavior.
>
> >> In the code, the "match_slash" function [1] is used to find
> >> the delimiters of the "s" command (typically "slashes").
> >> Special handling happens if a slash is found [2],
> >> And in lines 557-8 there's this conditional:
> >>
> >>                else if (ch == 'n' && regex)
> >>                  ch = '\n';
> >>
> >> Which forces any "\n" to be a new-line, regardless if the
> >> delimiter itself was an "n".
> >>
>
> >> Interestingly, removing these two lines does not cause
> >> any test failures, so this might be easy to fix without causing
> >> any regressions.
> >>
> >>
> >> For now I'm leaving this item open until we decide how to deal with it.
>
> I'm thus in favor of removing that special-case of 'n'.

Thank you all. Sorry it's taken so long.
I expect to push the following tomorrow.

Subject: n as delimiter alias
From: Oğuz <[email-masked]>
To: [email-masked]
Date: Thu, 26 Mar 2020 07:30:16 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

$ sed --version
sed (GNU sed) 4.7
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jay Fenlason, Tom Lord, Ken Pizzini,
Paolo Bonzini, Jim Meyering, and Assaf Gordon.
GNU sed home page: <https://www.gnu.org/software/sed/>.
General help using GNU software: <https://www.gnu.org/gethelp/>.
E-mail bug reports to: <[email-masked]>.

While '\t' matches a literal 't' when 't' is the delimiter, '\n' does not
match 'n' when 'n' is the delimiter. See:

$ echo t | sed 'st\ttt' | xxd
00000000: 0a                                       .
$
$ echo n | sed 'sn\nnn' | xxd
00000000: 6e0a

Is this a bug or is there a sound logic behind this?

-- 
Oğuz