[Please just send messages to the ML, I read the list] Ralf Wildenhues wrote: >> Kurt Roeckx <[EMAIL PROTECTED]> >> libtool > > Libtool is a false positive. The script /usr/bin/libtool contains some > C program text embedded in a here document.
Detection of that kind of stuff is already in latest checkbashisms and, hopefully, those false positives are gone. Atm, checkbashisms only complains with this: > _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb > possible bashism in ./usr/bin/libtool line 1218 (trap with signal numbers): > trap "$run $rm $removelist; exit $EXIT_FAILURE" 1 2 15 > possible bashism in ./usr/bin/libtool line 1237 (trap with signal numbers): > trap "$run $rm $removelist; exit $EXIT_FAILURE" 1 2 15 > possible bashism in ./usr/bin/libtool line 5323 (trap with signal numbers): > trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15 > possible bashism in ./usr/bin/libtool line 5676 (trap with signal numbers): > trap "$rm $output; exit $EXIT_FAILURE" 1 2 15 > > 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? I've seen some scripts testing for $BASH which works as expected: > $ bash <<< 'echo $BASH' > /bin/bash > $ dash <<< 'echo $BASH' > > > Cheers, > Ralf Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
