Re: config.sub/config.guess using nonportable $(...) substitutions

[Karl Berry]

1. $(...) breaks Solaris 10 /bin/sh.
2. Solaris 10 is still supported by the vendor, and people still use it
with GNU tools.
3. There is no technical benefit to $(...) in config.*.

What's the harm in using `...` a few more years in config.*?
Answer, as far as I can see: none. -k

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/9/21 12:26 PM, Paul Eggert wrote:

On 3/9/21 11:09 AM, Karl Berry wrote:


I fully disagree. (Along with, it seems, everyone else except
you and Ben.)


Ben is the main person to convince here, since he's the maintainer.


Oh, my mistake. Ben has stepped down, so I should have written that 
Dmitry is the main person to convince here, since he's the maintainer of 
'config' now.

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/9/21 11:09 AM, Karl Berry wrote:


I fully disagree. (Along with, it seems, everyone else except
you and Ben.)


Ben is the main person to convince here, since he's the maintainer.

I am a bit disenheartened to see that Ben hasn't sent any email to this 
list since he installed the change in question, back in November. If 
he's retired (which I hope not), we'll need to find a new maintainer 
whose lap we can dump this problem into. I'll cc this email to him to 
give him a heads-up about the thread.



1) There is no actual benefit to using $(...) over `...`.


I disagree with that statement on technical grounds (not merely cosmetic 
grounds), as I've run into real problems in using `...` along with " and 
\, problems that I would not have run into with $(...). The Autoconf 
manual describes some of these problems.[1]



Talking about # as an analogy is a red herring. # does not cause
real-life problem.


# caused a real-life problem for me on a real-life system, around 1979. 
Of course the problem set has changed since then, but the compatibility 
principle hasn't.


[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Shell-Substitutions.html

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/9/21 5:57 AM, Bob Friesenhahn wrote:

It seems that config.guess and Autotools packages are picking winners 
and losers.  It is not clear where the bar has been set.


I prefer to draw the line at systems that are no longer supported by 
their own suppliers. For Solaris, that means I worry only about Solaris 
10 and later, as Oracle no longer supports older versions.


However, this is not a boundary formally set by the GNU project, and 
different developers can choose different boundaries, as described in 
"Platforms to Support" section of the GNU software maintainers manual 
.


config.sub/config.guess are special in that they're shared among so many 
projects, and so the boundary that Ben uses affects a lot of projects' 
configuration code.

Re: config.sub/config.guess using nonportable $(...) substitutions

[Karl Berry]

At some point, failing to support $(...) is in the same ballpark 

FWIW, I fully disagree. (Along with, it seems, everyone else except
you and Ben.)

1) There is no actual benefit to using $(...) over `...`.
It is purely cosmetic. In other scripts, fine. In config.*, no.

2) Using $(...) causes a real-life problem on a real-life system.
Talking about # as an analogy is a red herring. # does not cause
real-life problem.

I just don't understand the overwhelming need to create this problem for
ourselves. -k

Re: config.sub/config.guess using nonportable $(...) substitutions

[Bob Friesenhahn]

On Mon, 8 Mar 2021, Paul Eggert wrote:

Except maybe for Solaris 10, shells that don't grok $(...) are museum pieces 
now. And anybody on Solaris 10 (which occasionally includes me, as my 
department still uses Solaris 10 on some machines) can easily run a better 
shell like /bin/ksh. It's a bit of a maintenance hassle for Ben to deal with


The script itself does start with requesting /bin/sh.  The 
config.guess script is also used in contexts outside of Autotools, 
although such usage can likely specify the shell to use when executing 
the script.


At some point, failing to support $(...) is in the same ballpark as failing 
to support "#". I can see Ben's point of view that we've reached that point 
even if I would have waited another three years, so if Ben would rather use 
$(...) I'd rather not overrule him downstream.


It seems that config.guess and Autotools packages are picking winners 
and losers.  It is not clear where the bar has been set.  When such 
decisions are made, it is useful if messaging about it is very clear.


If any component of a build infrastructure is not portable to an older 
system, then all of the components (including each dependent 
application's own configure.ac script) might as well be updated to use 
the less-portable yet more convenient modern syntax and this implies 
the ability to safely use other modern syntax as well.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: config.sub/config.guess using nonportable $(...) substitutions

[Tim Rice]

On Mon, 8 Mar 2021, Nick Bowler wrote:

> Hi,
> 
> I noticed that config.sub (and config.guess) scripts were very recently
> changed to use the POSIX $(...) form for command substitutions.
> 
> This change is, I fear, ill-advised.  The POSIX construction is
> widely understood to be nonportable as it is not supported by
> traditional Bourne shells such as, for example, Solaris 10 /bin/sh.
> This specific portability problem is discussed in the Autoconf manual
> for portable shell programming[1].
> 
> These scripts using $(...) are incorporated into the recently-released
> Automake 1.16.3, which means they get copied into packages bootstrapped
> with this version.  So now, if I create a package using the latest bits,
> configuring with heirloom-sh fails:
> 
>   % CONFIG_SHELL=/bin/jsh jsh ./configure CONFIG_SHELL=/bin/jsh
>   configure: error: cannot run /bin/jsh ./config.sub

But why would you use CONFIG_SHELL= to specify a less capable shell?
It is there to specify a more capable shell in case it is not already
detected.

Now if an autoconf built configure attempts to run config.guess/config.sub
before detecting a capapable shell and exec(ing) itself, then that is
not so good.

>   % jsh config.sub x86_64-pc-linux-gnu
>   config.sub: syntax error at line 53: `me=$' unexpected
> 
> (The heirloom-sh is essentially Solaris /bin/sh but runs on GNU/Linux 
> systems).

-- 
Tim RiceMultitalents
t...@multitalents.net

Re: config.sub/config.guess using nonportable $(...) substitutions

[Bob Friesenhahn]

On Mon, 8 Mar 2021, Nick Bowler wrote:


These scripts using $(...) are incorporated into the recently-released
Automake 1.16.3, which means they get copied into packages bootstrapped
with this version.  So now, if I create a package using the latest bits,
configuring with heirloom-sh fails:


This is bad and has immediate impact (and now already existing due to 
including in releases) to some projects.  Due to Autotools sometimes 
taking a long time between releases, some projects (including two I 
make releases for) update these scripts as part of their normal 
release process.


It is assumed that the scripts will remain portable to almost any 
system.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: config.sub/config.guess using nonportable $(...) substitutions

[Nick Bowler]

On 2021-03-08, Tim Rice  wrote:
> On Mon, 8 Mar 2021, Nick Bowler wrote:
[...]
>> These scripts using $(...) are incorporated into the recently-released
>> Automake 1.16.3, which means they get copied into packages bootstrapped
>> with this version.  So now, if I create a package using the latest bits,
>> configuring with heirloom-sh fails:
>>
>>   % CONFIG_SHELL=/bin/jsh jsh ./configure CONFIG_SHELL=/bin/jsh
>>   configure: error: cannot run /bin/jsh ./config.sub
>
> But why would you use CONFIG_SHELL= to specify a less capable shell?
> It is there to specify a more capable shell in case it is not already
> detected.

It is simply a proxy to test Solaris /bin/sh behaviour using a modern
GNU/Linux system.  This is much easier and faster than actually testing
on old Solaris systems and, more importantly, anyone can download and
install this shell as it is free software and reasonably portable.

Obviously I can successfully run my scripts on GNU/Linux using a modern
shell such as GNU Bash.  But that's not the point: Autoconf and friends
are first and foremost portability tools.  For me the goal is that this
should be working anywhere that anyone might reasonably want to run it.

But right now, it seems these portability tools are actually *causing*
portability problems, rather than solving them.  From my point of view
this is a not so great situation.

Cheers,
  Nick

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/8/21 3:00 PM, Dmitry V. Levin wrote:

The only rationale provided by the previous maintainer so far is a short
message in config-patches mailing list [1].


The config maintainer Ben Elliston has wanted to get rid of the 
old-fashioned accent graves for many years. In November 2017 he 
installed a change to do that, but I explained it wouldn't work well on 
Solaris 10 so he reverted. Two years ago he asked me about this again, 
and I responded that Solaris 10's end-of-life was scheduled to be 
January 2021 and so it'd be best to wait until then, and he agreed. Last 
April we emailed each other again about this, and I told him that Oracle 
had extended Solaris 10's end-of-life to January 2024 but he demurred, 
writing that he didn't want to wait the extra three years.


Except maybe for Solaris 10, shells that don't grok $(...) are museum 
pieces now. And anybody on Solaris 10 (which occasionally includes me, 
as my department still uses Solaris 10 on some machines) can easily run 
a better shell like /bin/ksh. It's a bit of a maintenance hassle for Ben 
to deal with `...` (it doesn't nest, and it has weird rules when 
combined with "...") and it's understandable that he would rather deal 
with actual config.guess problems than with completely-obsolete shells 
that don't support standard syntax.


I recall having a similar discussion back in the 1970s, when a shell 
script stopped working for me because its author put in a comment 
starting with "#", something the 7th Edition shell did not support. I 
wrote the author, who suggested I get a better shell, and life went on. 
And I'd expect a similar reaction today if someone asked us to remove 
the "#" comments from config.guess on the grounds that they don't work 
with Steve Bourne's original V7 shell.


At some point, failing to support $(...) is in the same ballpark as 
failing to support "#". I can see Ben's point of view that we've reached 
that point even if I would have waited another three years, so if Ben 
would rather use $(...) I'd rather not overrule him downstream.

Re: config.sub/config.guess using nonportable $(...) substitutions

[Dmitry V. Levin]

Hi,

On Mon, Mar 08, 2021 at 01:21:57PM -0500, Nick Bowler wrote:
> Hi,
> 
> I noticed that config.sub (and config.guess) scripts were very recently
> changed to use the POSIX $(...) form for command substitutions.
[...]
> What was the motivation for this change?  Backquotes work fine and are
> more portable.  Can we just revert it so the script works again with
> traditional shells?  Surely these scripts should be maximally portable,
> I would think?
> 
> [1] 
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#index-_0024_0028commands_0029

The only rationale provided by the previous maintainer so far is a short
message in config-patches mailing list [1].  

I tried to reach the author of that change [2], but, unfortunately,
received no response.

[1] https://lists.gnu.org/archive/html/config-patches/2020-11/msg00011.html
[2] https://lists.gnu.org/archive/html/config-patches/2020-12/msg6.html


-- 
ldv

config.sub/config.guess using nonportable $(...) substitutions

[Nick Bowler]

Hi,

I noticed that config.sub (and config.guess) scripts were very recently
changed to use the POSIX $(...) form for command substitutions.

This change is, I fear, ill-advised.  The POSIX construction is
widely understood to be nonportable as it is not supported by
traditional Bourne shells such as, for example, Solaris 10 /bin/sh.
This specific portability problem is discussed in the Autoconf manual
for portable shell programming[1].

These scripts using $(...) are incorporated into the recently-released
Automake 1.16.3, which means they get copied into packages bootstrapped
with this version.  So now, if I create a package using the latest bits,
configuring with heirloom-sh fails:

  % CONFIG_SHELL=/bin/jsh jsh ./configure CONFIG_SHELL=/bin/jsh
  configure: error: cannot run /bin/jsh ./config.sub

  % jsh config.sub x86_64-pc-linux-gnu
  config.sub: syntax error at line 53: `me=$' unexpected

(The heirloom-sh is essentially Solaris /bin/sh but runs on GNU/Linux systems).

What was the motivation for this change?  Backquotes work fine and are
more portable.  Can we just revert it so the script works again with
traditional shells?  Surely these scripts should be maximally portable,
I would think?

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#index-_0024_0028commands_0029

Cheers,
  Nick