On a related topic: I'm fighting a bug in the gcc build process
right now that is caused directly by the lack of the posix $()
construct. (It's exactly the need to be able to do $(...$(...)...) ,
which can't be done with backtick (`) in any reasonable way
in the presence of quoting and multiple levels of argument
passing to subshells.)
>From my point of view, although using functions would be nice,
allowing $() is far more useful and necessary, because in some
instances there is no reasonable alternative. The question is,
exactly how much to we have to hobble ourselves by insisting
on "too old" a shell. Posix.2 has been out 8 years now (and $()
was clearly coming for several years before that.) In this case,
even if autoconf doesn't really need it (and it may or may not),
it certainly would be useful in gcc proper.
Speaking only for myself.
Donn Terry
> -----Original Message-----
> From: Paul Eggert [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 08, 2000 1:48 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: rfc: new libgcc build mechanism
>
>
> From: Per Bothner <[EMAIL PROTECTED]>
> Date: 08 May 2000 06:53:13 -0700
>
> I do not see 4.3BSD as a reason to not use functions in
> shell scripts.
...snip
> GCC is different. I agree with Per Bothner that nowadays GCC build
> scripts can use shell functions if it seems advisable. The decision
> to use shell functions shouldn't be made lightly: GCC should try to
> support traditional Bourne shells if possible, particularly if someone
> volunteers to maintain this support. But if it's an undue maintenance
> burden to support these old shells then I think it's reasonable to
> drop it.
>
