GNU bug report logs - #59444
ADVICE-ON-FAILURE sed syntax error

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59444 in the body.
You can then email your comments to 59444 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>
Subject: ADVICE-ON-FAILURE sed syntax error
Date: Mon, 21 Nov 2022 12:51:05 +0100

Right now on Emacs master (d9d8a2eba9), any build error results in

***
*** "make all" failed with exit status 2.
***
sed: 1: "/^# ADVICE-ON-FAILURE-B ...": extra characters at the end of q command
make[1]: *** [advice-on-failure] Error 1
make: *** [all] Error 2

which is less than helpful. (This is with macOS 11.7, system tools.)

The bug is here somewhere (Makefile.in:413):

  sed -n '/^# ADVICE-ON-FAILURE-BEGIN:${make-target}/,$${p;/^# ADVICE-ON-FAILURE-END:${make-target}/q};'

Any reason why this isn't just written

  sed -n '/^# ADVICE-ON-FAILURE-BEGIN:${make-target}/,/^# ADVICE-ON-FAILURE-END:${make-target}/p'

? The latter would work with any standard `sed`.

Message #10 received at 59444-done <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 59444-done <at> debbugs.gnu.org
Subject: Re: bug#59444: ADVICE-ON-FAILURE sed syntax error
Date: Mon, 21 Nov 2022 12:49:50 +0000

Thanks for your bug report.

>
> Right now on Emacs master (d9d8a2eba9), any build error results in
>

Is this new?  That part of the Makefile hasn't changed in the last two 
months, after it was introduced.

>
> The bug is here somewhere (Makefile.in:413):
>
> sed -n '/^# ADVICE-ON-FAILURE-BEGIN:${make-target}/,$${p;/^# ADVICE-ON-FAILURE-END:${make-target}/q};'
>
> Any reason why this isn't just written
>
> sed -n '/^# ADVICE-ON-FAILURE-BEGIN:${make-target}/,/^# ADVICE-ON-FAILURE-END:${make-target}/p'
>
> ? The latter would work with any standard `sed`.
>

Again I tested this with (GNU) sed with --posix, and it gave the expected 
result.  The reason I chose the former expression instead of the latter is 
because it's how I usually write such patterns.  After reading the POSIX 
standard, it turns out that a semicolon is required after the 'q'.  Fixed 
(a3b654e069) and closing.

Message #13 received at 59444 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 59444 <at> debbugs.gnu.org
Subject: Re: bug#59444: ADVICE-ON-FAILURE sed syntax error
Date: Mon, 21 Nov 2022 14:11:14 +0100

21 nov. 2022 kl. 13.49 skrev Gregory Heytings <gregory <at> heytings.org>:

> Again I tested this with (GNU) sed with --posix, and it gave the expected result.

Then what we should learn from this is that GNU sed --posix cannot be trusted blindly to reject non-POSIX features.
This is unsurprising -- it can be difficult to keep all extensions from leaking past the gate.

>  The reason I chose the former expression instead of the latter is because it's how I usually write such patterns.

That doesn't answer the question. Why that roundabout way, rather than the simpler direct approach?

> Fixed (a3b654e069) and closing.

That seems to work. Thank you!

Message #16 received at 59444 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 59444 <at> debbugs.gnu.org
Subject: Re: bug#59444: ADVICE-ON-FAILURE sed syntax error
Date: Mon, 21 Nov 2022 13:17:47 +0000

>> Again I tested this with (GNU) sed with --posix, and it gave the 
>> expected result.
>
> Then what we should learn from this is that GNU sed --posix cannot be 
> trusted blindly to reject non-POSIX features. This is unsurprising -- it 
> can be difficult to keep all extensions from leaking past the gate.
>

Do you know of any computer program that can be trusted blindly? ;-)

>> The reason I chose the former expression instead of the latter is 
>> because it's how I usually write such patterns.
>
> That doesn't answer the question. Why that roundabout way, rather than 
> the simpler direct approach?
>

I write such expressions that way because with that expression only the 
first matching block is printed.  Which is admittedly not important in 
this case, but habits being what they are...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.