I agree that finding it may be a bit of a challenge, but
it's probably worth it. (I'll see what I can do about
making that better in another life ;-) ).
The specific case I'm dealing with involves passing the
CC command down to lower levels of make, which in turn
involves doing command substitutions at various levels.
The current partial solution involves having two the-same-but-different
versions of the same string, with different levels of \ quoting
of ` (to allow nesting of `). Since the problem being addressed
is finding filenames, finding the filename of a temp file
introduces a recursion. (All this may be solvable, but it's
far more difficult than it needs to be: $() was created
to allow just that.) (A recent change broke the currently
working solution.) (Look at @quoted_cc_set_by_configure@
in configure and Makefile.in, and how to make that work
(reasonably) in the context of SUBDIR_FLAGS_TO_PASS,
when symbolic links are not present.)
Donn
> -----Original Message-----
> From: Robert Lipe [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 08, 2000 8:13 PM
> To: Donn Terry
> Cc: 'Russ Allbery '; '[EMAIL PROTECTED] '; '[EMAIL PROTECTED] '
> Subject: Re: rfc: new libgcc build mechanism
>
>
> > 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
>
