bug#57949: git head; unportable test(1) operator

bug#57949: git head; unportable test(1) operator

[Thomas Klausner]

Hi!

In
https://github.com/emacs-mirror/emacs/commit/7c8a131984ab47349381975dead1712ae25ae2c6
Makefile.in started using "==" as test(1) comparison operator.

This is not portable, only bash supports it. POSIX mandates "=".

Please apply the following patch:

--- Makefile.in.orig    2022-09-19 23:17:34.000000000 +0000
+++ Makefile.in
@@ -417,7 +417,7 @@ sanity-check:
        @v=$$(src/emacs${EXEEXT} --batch --eval \
          '(progn (defun f (n) (if (= 0 n) 1 (* n (f (- n 1))))) (princ (f 10)))' \
          2> /dev/null); \
-       [ "X$$v" == "X3628800" ] && exit 0; \
+       [ "X$$v" = "X3628800" ] && exit 0; \
        echo; \
        echo "  \"make ${make-target}\" succeeded, but Emacs is not functional."; \
        cat Makefile | \

Thanks,
 Thomas

bug#57949: git head; unportable test(1) operator

[Gregory Heytings]

>
> Makefile.in started using "==" as test(1) comparison operator.
>
> This is not portable, only bash supports it. POSIX mandates "=".
>

Thanks, fixed!

bug#57949: git head; unportable test(1) operator

[Eli Zaretskii]

> Resent-To: bug-gnu-emacs@gnu.org
> Cc: 57949-done@debbugs.gnu.org
> Date: Tue, 20 Sep 2022 09:22:16 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> > Makefile.in started using "==" as test(1) comparison operator.
> >
> > This is not portable, only bash supports it. POSIX mandates "=".
> 
> Thanks, fixed!

Gregory, why are there ZERO-WIDTH SPACE characters in the top-level
Makefile.in?  What purpose do they server, and why cannot we do the
same with ASCII characters?

bug#57949: git head; unportable test(1) operator

[Gregory Heytings]

>>> Makefile.in started using "==" as test(1) comparison operator.
>>>
>>> This is not portable, only bash supports it. POSIX mandates "=".
>>
>> Thanks, fixed!
>
> Gregory, why are there ZERO-WIDTH SPACE characters in the top-level 
> Makefile.in?  What purpose do they server, and why cannot we do the same 
> with ASCII characters?
>

Their purpose is to make the text behave exactly like the "CC", "ELC", 
"GEN", "INFO", ... messages printed by make.  If it's problematic to have 
zero-width space characters there, they could be removed and/or replaced 
by something else.

bug#57949: git head; unportable test(1) operator

[Eli Zaretskii]

> Date: Tue, 20 Sep 2022 11:54:55 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 57949@debbugs.gnu.org
> 
> 
> >>> Makefile.in started using "==" as test(1) comparison operator.
> >>>
> >>> This is not portable, only bash supports it. POSIX mandates "=".
> >>
> >> Thanks, fixed!
> >
> > Gregory, why are there ZERO-WIDTH SPACE characters in the top-level 
> > Makefile.in?  What purpose do they server, and why cannot we do the same 
> > with ASCII characters?
> >
> 
> Their purpose is to make the text behave exactly like the "CC", "ELC", 
> "GEN", "INFO", ... messages printed by make.

I don't think I understand -- what do you expect to happen, as
opposed to when these are removed?

> If it's problematic to have zero-width space characters there, they
> could be removed and/or replaced by something else.

Depending on how you view them, they could appear as "<U+200B>", in
inverse video, on a terminal's display.  Which stands out and gets in
the way of reading.

bug#57949: git head; unportable test(1) operator

[Gregory Heytings]

>> If it's problematic to have zero-width space characters there, they 
>> could be removed and/or replaced by something else.
>
> Depending on how you view them, they could appear as "<U+200B>", in 
> inverse video, on a terminal's display.  Which stands out and gets in 
> the way of reading.
>

Indeed.  I've now changed the way the message is displayed, it now uses 
three leading stars and is redirected to stderr, which is e.g. what the 
Linux kernel uses.

bug#57949: git head; unportable test(1) operator

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Their purpose is to make the text behave exactly like the "CC", "ELC",
> "GEN", "INFO", ... messages printed by make.  If it's problematic to
> have zero-width space characters there, they could be removed and/or
> replaced by something else.

I think saying WARNING: instead would probably be clearer.