bug#59444: ADVICE-ON-FAILURE sed syntax error

bug#59444: ADVICE-ON-FAILURE sed syntax error

[Mattias Engdegård]

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

bug#59444: ADVICE-ON-FAILURE sed syntax error

[Gregory Heytings]

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.

bug#59444: ADVICE-ON-FAILURE sed syntax error

[Mattias Engdegård]

21 nov. 2022 kl. 13.49 skrev Gregory Heytings <gregory@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!

bug#59444: ADVICE-ON-FAILURE sed syntax error

[Gregory Heytings]

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