Re: rfc: new libgcc build mechanism

[Robert Lipe <robertlipe at usa dot net>]

> the GNU assumption that /bin/sh is the one and only shell
> leads to a permanent deadlock.  Vendors don't want to break
> user's existant shell scripts, and there are some corner
> cases in the Bourne shell that are not completely compatible
> with a POSIX shell.  Thus, vendors who have taken this route
> will NEVER (OK... "never say never") replace the Bourne shell
> (as /bin/sh) with a POSIX shell.  Thus, to the same degree

This is exactly the problem.  While most (at least most System V's) do
have a bourne shell that accepts shell functions most vendor /bin/sh
programs are not the POSIX shell.

So while most modern systems do have a shell _somewhere_ that meets the
POSIX standard, the challenge is to find it.  Of course, that could be
done in an autoconf-like system.

> Bourne shell.  However, if we ask a different question: can
> we count on there being a POSIX shell by some name or other
> (and thus figure out how to find that) then I think there's

The only two ways that I know of are to look in the documentation that
the vendor had to file at certification time and to look through a list
of "well known" locations.

> no requirement about which directory it lives in (and this
> is what allows POSIX conformance systems to layer the path
> such that /bin/sh doesn't change behavior but POSIX conformant
> applications work).)

Right.   And it allows it to be "hidden" in a zillion different places.
Certainly, there is prior art in autoconf roaming the directory tree for
such things, but it's really icky.


But my gut tells me that while shell functions are probably "common
enough" to be used on interesting systems with little pain, the tradoffs
and paybacks of finding the posix shell will deliver q different value
equation.

RJL