Re: config.sub/config.guess using nonportable $(...) substitutions
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
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
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
Hi Dmitry, I tried to reach the author of that change [2], but, unfortunately, received no response. Ben's lack of response is no reason not to revert this unportability. After all, one steps down from maintainership in order not to spend time thinking about it any more. Clearly Ben had no technical reason for the change; it only causes problems. I hope you're willing to revert it. As I've written several times before :). Thanks, Karl
Re: config.sub/config.guess using nonportable $(...) substitutions
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
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
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
