FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-31-2008, 03:07 PM
Raphael Geissert
 
Default 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
 
Old 01-31-2008, 04:23 PM
Petter Reinholdtsen
 
Default 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
 
Old 01-31-2008, 05:11 PM
Bernd Zeimetz
 
Default 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.


Best regards,

Bernd


--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2008, 09:32 PM
Ralf Wildenhues
 
Default 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
 
Old 02-09-2008, 11:08 PM
Raphael Geissert
 
Default 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:

> $ bash <<< 'echo $BASH'
> /bin/bash
> $ dash <<< 'echo $BASH'
>

>
> Cheers,
> Ralf

Cheers,
Raphael Geissert


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-09-2008, 11:39 PM
Russ Allbery
 
Default List of packages shipping shell scripts with bashisms + MBF proposal

Raphael Geissert <atomo64+debian@gmail.com> writes:

> 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.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-09-2008, 11:59 PM
Ben Pfaff
 
Default List of packages shipping shell scripts with bashisms + MBF proposal

Raphael Geissert <atomo64+debian@gmail.com> writes:

> 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
 
Old 02-10-2008, 12:04 AM
Ben Pfaff
 
Default 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
 
Old 02-10-2008, 12:24 AM
Russ Allbery
 
Default 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.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-10-2008, 01:13 AM
Russ Allbery
 
Default 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.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org