List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert wrote:
>
> Since there's a release goal which is to default /bin/sh to dash I'd like
> to do a MBF on the packages. It would be a manual MBF because there are
> many false positives which I wouldn't want to be reported.
>
> Besides providing this list so people can start fixing those bashisms I
> now ask if there are any objections on starting to MBF based on the test
> results. Of course any other kind of feedback is more than welcome.
>
No objections to start MBF then?
Cheers,
Raphael Geissert
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-31-2008, 04:23 PM
Petter Reinholdtsen
List of packages shipping shell scripts with bashisms + MBF proposal
[Raphael Geissert]
> No objections to start MBF then?
Not from me, at least. Make sure to usertag the bugs properly,
though, as a release goal bug. (tag goal-dash, user debian-release@).
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-31-2008, 05:11 PM
Bernd Zeimetz
List of packages shipping shell scripts with bashisms + MBF proposal
> I just completed an archive wide check on amd64/all packages by searching
> for shell scripts in /bin:/usr/bin:/sbin:/usr/sbin:/etc/init.d:/usr/share
> and checking them with checkbashisms from devscripts 2.10.13.
script ./usr/bin/foo does not appear to be a /bin/sh script; skipping
.... you should not list this as a problem. If a script is not a sh
script, there's no reason to check for bashisms imho, especially if you
have scripts for psh, ksh, csh or other weird shells.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-08-2008, 09:32 PM
Ralf Wildenhues
List of packages shipping shell scripts with bashisms + MBF proposal
> Kurt Roeckx <kurt@roeckx.be>
> libtool
Libtool is a false positive. The script /usr/bin/libtool contains some
C program text embedded in a here document.
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.
Cheers,
Ralf
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-09-2008, 11:08 PM
Raphael Geissert
List of packages shipping shell scripts with bashisms + MBF proposal
[Please just send messages to the ML, I read the list]
Ralf Wildenhues wrote:
>> Kurt Roeckx <kurt@roeckx.be>
>> 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:
> 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
This one is somewhat arguable. Pure POSIX doesn't allow signal numbers,
but the XSI extension to POSIX does and dash and posh both support them.
We do not, in general, accept XSI extensions, but it's hard to argue
strongly for excluding a feature that even posh supports.
> 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):
It's weird that it calls this a "possible bashism". It's not a
bashism (at most, it's an XSI-ism) and it's so pervasively
supported that even Autoconf uses it.
--
Ben Pfaff
http://benpfaff.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-10-2008, 12:04 AM
Ben Pfaff
List of packages shipping shell scripts with bashisms + MBF proposal
Russ Allbery <rra@debian.org> writes:
> Pure POSIX doesn't allow signal numbers, but the XSI extension
> to POSIX does and dash and posh both support them. We do not,
> in general, accept XSI extensions, but it's hard to argue
> strongly for excluding a feature that even posh supports.
Is there a good reason that we do not in general accept XSI
extensions? The ones that I've noticed while reading SUSv3 are
features that I expect a normal Unix system to have.
--
Ben Pfaff
http://benpfaff.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-10-2008, 12:24 AM
Russ Allbery
List of packages shipping shell scripts with bashisms + MBF proposal
Ben Pfaff <blp@cs.stanford.edu> writes:
> Russ Allbery <rra@debian.org> writes:
>> Pure POSIX doesn't allow signal numbers, but the XSI extension to POSIX
>> does and dash and posh both support them. We do not, in general,
>> accept XSI extensions, but it's hard to argue strongly for excluding a
>> feature that even posh supports.
> Is there a good reason that we do not in general accept XSI extensions?
> The ones that I've noticed while reading SUSv3 are features that I
> expect a normal Unix system to have.
I don't remember exactly which ones there were, but when I did some more
comprehensive research a while back, there were several major ones that
weren't supported by dash. Since one of the practical points for this
whole exercise is to let people use dash as /bin/sh, since it can be much
faster, that seemed like a good argument against it.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-10-2008, 01:13 AM
Russ Allbery
List of packages shipping shell scripts with bashisms + MBF proposal
Clint Adams <schizo@debian.org> writes:
> Since 0.5.6, it does not; the only number it understands is the
> pseudo-signal 0, mandated by POSIX.
Oh, sorry, you're of course correct. I missed the 0 == n test in
gettrap(). Sorry about the confusion.
> The reason POSIX doesn't allow numbers is that they are inconsistent
> from platform to platform. People who learn signals on a commercial OS
> of yore sometimes assume that signal 5 means something other than
> SIGTRAP on Debian, and script traps and kills that end up not doing what
> is intended.
This is a good point. However, it's worth noting that the XSI extension
to POSIX doesn't allow you to use just any numbers. It specifically lets
you use numbers for HUP, INT, QUIT, ABRT, KILL, ALRM, and TERM and nothing
else. I think that's fairly portable.
List of packages shipping shell scripts with bashisms + MBF proposal
