Re: Re: List of packages shipping shell scripts with bashisms + MBF proposal
[ Please Cc: me, I don't read the list ]
* Raphael Geissert wrote:
> > I should further note that the Libtool version in experimental makes
> > use of some bashisms as optimization. These are put in place iff, at
> > the time the Libtool package is configured, the chosen shell is deemed
> > capable enough. This setup can break /usr/bin/libtool, for example, if
> > /bin/sh is later switched from bash to dash.
>
> Why not just check if the shell is bash at run time?
Well, we check for two different things, some XSI extensions, and +=
support. We replace shell functions based on the result.
This could probably be done at run time, but then, typically, care must
be taken to do the check in a subshell, and the resulting shell function
definition in an eval expression. This is needed because libtool also
supports very ancient and otherwise borked shells, like the Solaris one.
Both of these actions are relatively slow operations, esp. the two extra
forks would probably increase build time of some projects using libtool
by a few percent. (CVS HEAD libtool compile mode uses typically 10
forks or less and 3 execs with a capable shell.)
Since this is so far the only issue I know with this, I'll wait for a
bug report before doing anything about it (and even then, I'll probably
consider just making /usr/bin/libtool more flexible, but not libtool
scripts generated inside user packages).
> I've seen some scripts testing for $BASH which works as expected:
We don't want to delimit ourselves to bash; the XSI extensions work fine
with several other shells; however, += only works with recent bash (>=
3.2), so testing for $BASH is not useful.
Cheers,
Ralf
Reply to: