GNU bug report logs - #57949
git head; unportable test(1) operator

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 57949 in the body.
You can then email your comments to 57949 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: Thomas Klausner <wiz <at> gatalith.at>
To: bug-gnu-emacs <at> gnu.org
Subject: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 09:08:52 +0200

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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Thomas Klausner <wiz <at> gatalith.at>
Cc: 57949-done <at> debbugs.gnu.org
Subject: Re: bug#57949: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 09:22:16 +0000

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

Thanks, fixed!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 57949 <at> debbugs.gnu.org, wiz <at> gatalith.at
Subject: Re: bug#57949: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 14:51:23 +0300

> Resent-To: bug-gnu-emacs <at> gnu.org
> Cc: 57949-done <at> debbugs.gnu.org
> Date: Tue, 20 Sep 2022 09:22:16 +0000
> From: Gregory Heytings <gregory <at> 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?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57949 <at> debbugs.gnu.org
Subject: Re: bug#57949: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 11:54:55 +0000

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 57949 <at> debbugs.gnu.org
Subject: Re: bug#57949: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 15:00:02 +0300

> Date: Tue, 20 Sep 2022 11:54:55 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 57949 <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57949 <at> debbugs.gnu.org
Subject: Re: bug#57949: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 14:20:31 +0000

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 57949 <at> debbugs.gnu.org
Subject: Re: bug#57949: git head; unportable test(1) operator
Date: Tue, 20 Sep 2022 17:24:26 +0200

Gregory Heytings <gregory <at> 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.

Previous Next

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