[ 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
