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

[David A. Wheeler]

> On Mar 9, 2021, at 5:08 PM, Zack Weinberg  wrote:
> N.B. I changed Autoconf's "find us a better shell" logic in 2.70 to
> include checking for $(...) _specifically because of_ the change being
> debated here.  Configure scripts themselves still use `...`
> nigh-exclusively.

This seems like the right approach: First find a useful shell with $(...), then 
use that shell.
This localized the pain to the “find a shell” bootstrap.
I suspect many program-specific scripts use $(...),
so this will actually *increase* the portability of the final result.

--- David A. Wheeler

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

[Russ Allbery]

Warren Young  writes:

> Since all versions of Solaris postdate this, Sun really should have made
> /bin/sh a POSIX shell from the start, but for whatever reason, did not,
> and now that decision's causing us problems.

My recollection is that there was concern at the time with portability of
shell scripts written for SunOS.  Sun chose to keep /bin/sh (and various
other tools) compatible with SunOS rather than compatible with POSIX and
introduced the /usr/xpg4 path for those who wanted POSIX behavior.  That
trade-off of immediate compatibility for future pain has been causing
future pain ever since.

Interestingly, at around the same time they made that decision, they also
dropped bcopy and bzero from the standard library, provoking a ton of
porting problems.  (They reversed that decision later and added them
back.)

-- 
Russ Allbery (ea...@eyrie.org) 

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

[Warren Young]

On Tue, Mar 9, 2021 at 2:50 PM Michael Orlitzky 
wrote:

>
> the $(...) syntax was standardized no later than 1997


It was first formally standardized as part of the POSIX shell in 1989,
which standardized what used to be called ksh88

.

Since all versions of Solaris postdate this, Sun really should have made
/bin/sh a POSIX shell from the start, but for whatever reason, did not, and
now that decision's causing us problems.

I doubt the feature was added to ksh in 1988, since Kornshell has roots
going back to 1982, even though it wasn't formally made part of Unix® until
SVR4 in 1988.

If you're seeing all this 1988 and 1989 stuff and wondering if there's a
coincidence, no, there isn't. POSIX was originally a formalization of SVR4
Unix, meant to heal the rift with BSD. How well that worked is a matter of
history. The point is, what we now call the standard Unix shell dates to
this time. In an ideal world, we'd have been able to depend on $() flavor
command substitution since 1989-1992, depending on where you date
the beginning of POSIX-certified Unixes.

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

[Zack Weinberg]

On Tue, Mar 9, 2021 at 5:00 PM Tim Rice  wrote:
> On Tue, 9 Mar 2021, Warren Young wrote:
> > On Mar 9, 2021, at 1:26 PM, Paul Eggert  wrote:
> > Solaris 10 dates from early 2005.  We gave it 16 years of direct support, 
> > and now it’s on a sort of “extended” support if you point Autoconf 
> > configure scripts at a reasonable shell.
>
> The thing is, it is not even necessary to point Autoconf configure
> scripts at a reasonable shell. The configure script will find a capable
> shell and run itself with that shell.
>
> UnixWare has a /bin/sh as crufty as Solaris 10. I just pulled the
> latest config.guess and config.sub into my OpenSSH tree and configure
> was just as happy as before. Like Solaris /bin/sh, UniWare's does
> not handle $(...) either.

N.B. I changed Autoconf's "find us a better shell" logic in 2.70 to
include checking for $(...) _specifically because of_ the change being
debated here.  Configure scripts themselves still use `...`
nigh-exclusively.

I don't want to either tear down or defend Ben's change, but it's my
personal opinion that use of $(...) is a lot more defensible in a
configure script than in config.{sub,guess}, because it _has_ that
"find a better shell" step at the beginning.  Also, configure would
get more out of being able to use $(...) than config.{sub,guess} do,
just because its code is typically more complicated, and configure
scripts tend to pull in third-party code from all over the place that
may or may not ever have been tested on anything old.  For these
reasons I probably wouldn't revert the Autoconf change even if the
config.{sub,guess} change were reverted.

zw

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

[Nick Bowler]

On 09/03/2021, Warren Young  wrote:
> On Mar 9, 2021, at 1:26 PM, Paul Eggert  wrote:
>>
>>> 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
>> \,
>
> Me too, plus nesting.  The difference is most definitely not cosmetic.

I think what Karl means is that it is usually very easy to portably work
around the problems of nested and/or quoted `...` substitutions (usually
by just using a variable).

In other words, the difference between a script using $(...) and an
equivalent, more portable script using `...` is only one of appearance.

Regardless, there are no quoted or nested substitutions whatsoever in
config.sub.  I see exactly one nested substitution in config.guess, and
just a handful of quoted ones.  None appear particularly challenging to
write portably.

> Autoconf came out in 1991, so it’s the equivalent of supporting Version 6
> Unix (1975) in the original release, which it probably didn’t do, given that
> the Bourne shell didn’t even exist at that point.
>
> Are the malcontents not expecting heroic levels of backwards compatibility
> that Autoconf never has delivered?

No, I'm just expecting that things are not broken gratuitously in core
portability tools because someone does not like the appearance of the
more portable syntax.

I _especially_ don't expect this kind of breakage when upgrading from one
Automake point release to another (1.16.1 to 1.16.3).

Cheers,
  Nick

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

[Tim Rice]

On Tue, 9 Mar 2021, Warren Young wrote:

> On Mar 9, 2021, at 1:26 PM, Paul Eggert  wrote:
> Solaris 10 dates from early 2005.  We gave it 16 years of direct support, and 
> now it’s on a sort of “extended” support if you point Autoconf configure 
> scripts at a reasonable shell.

The thing is, it is not even necessary to point Autoconf configure
scripts at a reasonable shell. The configure script will find a capable
shell and run itself with that shell.

UnixWare has a /bin/sh as crufty as Solaris 10. I just pulled the
latest config.guess and config.sub into my OpenSSH tree and configure
was just as happy as before. Like Solaris /bin/sh, UniWare's does
not handle $(...) either.

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

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

[Michael Orlitzky]

On Tue, 2021-03-09 at 14:11 -0700, Warren Young wrote:
> 
> Solaris 10 dates from early 2005.  We gave it 16 years of direct
> support, and now it’s on a sort of “extended” support if you point
> Autoconf configure scripts at a reasonable shell.
> 

I didn't realize it was that "recent." I'm typing this on a PC (and OS
install) older than that. Digging through The Open Group archives shows
that the $(...) syntax was standardized no later than 1997, making me
less sympathetic than I was originally.

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

[Todd C. Miller]

On Tue, 09 Mar 2021 14:11:36 -0700, Warren Young wrote:

> That’s the real trick, isn’t it?  We have to set *some* threshold for droppin
> g support for old platforms.  I expect Autoconf isn’t compatible with Ultrix 
> any more, for instance.

That's a good reminder that we've been here before.  I remember
being somewhat irked when autoconf stopped working with the SunOS
4.x /bin/sh (due to the use of shell functions IIRC).  When I found
that bash would process the script far faster than the V7-derived
shell could I didn't mind any more :-)

And as Paul pointed out earlier, Solaris 10 has multiple shells
that support $( cmd ) syntax, they just aren't called /bin/sh.

 - todd

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

[Warren Young]

On Mar 9, 2021, at 1:26 PM, Paul Eggert  wrote:
> 
>> 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 \,

Me too, plus nesting.  The difference is most definitely not cosmetic.

> # caused a real-life problem for me on a real-life system, around 1979.

That’s the real trick, isn’t it?  We have to set *some* threshold for dropping 
support for old platforms.  I expect Autoconf isn’t compatible with Ultrix any 
more, for instance.

Solaris 10 dates from early 2005.  We gave it 16 years of direct support, and 
now it’s on a sort of “extended” support if you point Autoconf configure 
scripts at a reasonable shell.

Autoconf came out in 1991, so it’s the equivalent of supporting Version 6 Unix 
(1975) in the original release, which it probably didn’t do, given that the 
Bourne shell didn’t even exist at that point.

Are the malcontents not expecting heroic levels of backwards compatibility that 
Autoconf never has delivered?

What’s the limit?

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