List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert
Hash: SHA1
Hello everybody,
[Please only reply to -devel]
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.
The pourpose of this check was to help and ease the dash as /bin/sh release
goal/transition.
The current number of affected packages based on the scan is 249.
The results of this check may (and as confirmed in some packages) contain
false positives, and of course it isn't an absolute list (there are several
other bashisms that aren't detected, e.g. #462173).
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.
The full scan results are available as a compressed tarball[1], where
each .deb file is a plain text file containing the output of checkbashisms.
[1]http://alioth.debian.org/~atomo64-guest/bashisms-amd64-0.1.tar.gz
Kind regards,
Raphael Geissert
Daniel Leidert (dale) <daniel....@wgdd.de>
docbook2x (U)
Guenter Geiger (Debian/GNU) <gei...@debian.org>
wavesurfer
Gregory Colpart (evolix) <r...@evolix.fr>
pppoeconf
Stefan Hornburg (Racke) <ra...@linuxia.de>
courier-pop
courier-pop-ssl
sqwebmail
Eric Schwartz (Skif) <emsc...@debian.org>
libyaz2-dev
Stefan Alfredsson <al...@debian.org>
monit
Thomas Anders <tan...@users.sourceforge.net>
libsnmp-base (U)
Micah Anderson <mi...@debian.org>
rkhunter
Hakan Ardo <ha...@debian.org>
gcc-avr
Ben Armstrong <sy...@sanctuary.nslug.ns.ca>
tuxpaint
Richard Atterer <att...@debian.org>
jigdo-file
Khalid Aziz <kha...@debian.org>
kexec-tools
Mathieu Baeumler <mathieu....@gmail.com>
blackbox (U)
Paul Bame <ba...@debian.org>
pmccabe
Denis Barbier <bar...@debian.org>
kbd (U)
Andreas Barth <a...@not.so.argh.org>
netpbm
pppoe
Mirco Bauer <mee...@debian.org>
beagle (U)
mono-1.0-devel (U)
Daniel Baumann <dan...@debian.org>
expect-dev
gnulib
gnunet-client (U)
live-initramfs (U)
virtualbox-ose (U)
wmii
Ian Beckwith <ia...@nessie.mcc.ac.uk>
surfraw (U)
Luca Bedogni <m...@lucabedogni.it>
foo2zjs (U)
Hilko Bengen <ben...@debian.org>
virtualbox-ose (U)
Felix Berger <felix...@beldesign.de>
phpix (U)
Marco Bertorello <ma...@bertorello.ns0.it>
powernowd
Marcus Better <mar...@better.se>
tomcat5.5 (U)
Sylvain Beucler <be...@beuc.net>
page-crunch
Rene van Bevern <r...@debian.org>
cl-launch (U)
Darren Blaber <dmb...@gmail.com>
atheme-services (U)
Julien BLACHE <jbl...@debian.org>
openser (U)
Eduard Bloch <bl...@debian.org>
encfs
mono-1.0-devel (U)
Achim Bohnet <a...@mpe.mpg.de>
kdebluetooth (U)
W. Borgert <deb...@debian.org>
docbook2x (U)
Dmitry Borodaenko <angd...@debian.org>
samizdat
Fathi Boudra <fa...@debian.org>
kdebluetooth (U)
Fathi Boudra <fbo...@free.fr>
kdesdk-scripts (U)
Nicholas Breen <nbr...@ofb.net>
jigl
Adrian Bridgett <brid...@debian.org>
xmcd
Thomas Bushnell, BSG <t...@debian.org>
gnucash
jacal
slib
Bruno Barrera C. <br...@debian.org>
blackbox
Paul Cager <paul-...@home.paulcager.org>
maven2 (U)
Hubert Chan <uho...@debian.org>
noweb
Hubert Chathi <uho...@debian.org>
gnustep-common (U)
gnustep-make-ogo (U)
Pierre Chifflier <pol...@debian.org>
nufw
Volker Christian <v...@debian.org>
synce-serial
Dennis L. Clark <dbu...@debian.org>
bnetd
Isaac Clerencia <is...@debian.org>
kexi (U)
David Cobac <david...@free.fr>
page-crunch (U)
David Coe <dav...@debian.org>
ispell
Console utilities maintainers <pkg-kb...@lists.alioth.debian.org>
kbd
Julien Cristau <julien....@ens-lyon.org>
ocaml-mode (U)
Luis Rodrigo Gallardo Cruz <rod...@debian.org>
sawfish
Maximiliano Curia <ma...@gnuservers.com.ar>
tkman
Tim Cutts <ti...@chiark.greenend.org.uk>
tkcvs
Julien Danjou <ac...@debian.org>
rebuildd
Debian allegro packages maintainers
<pkg-allegro...@lists.alioth.debian.org>
allegro-examples
libalogg-dev
Debian ALSA Maintainers <pkg-als...@lists.alioth.debian.org>
ld10k1
Debian CLI Applications Team <pkg-cli-...@lists.alioth.debian.org>
beagle
Debian Cryptsetup Team <pkg-crypts...@lists.alioth.debian.org>
cryptsetup
Debian Cyrus SASL Team
<pkg-cyrus-sasl...@lists.alioth.debian.org>
sasl2-bin
Debian Foo2zjs Maintainers <foo2zjs-m...@lists.alioth.debian.org>
foo2zjs
Debian GCC Maintainers <debia...@lists.debian.org>
gcc-3.3
gcc-3.4
gcc-4.1
Debian GIS Project <pkg-gra...@lists.alioth.debian.org>
gpsdrive-scripts
Debian GNOME Maintainers <pkg-gnome-...@lists.alioth.debian.org>
gtranslator (U)
Debian GNUstep maintainers <pkg-gnustep...@lists.alioth.debian.org>
gnustep-common
gnustep-make-ogo
Debian Hamradio Maintainers <debia...@lists.debian.org>
ax25-tools
hf
Debian Hebrew Packaging Team <debian-heb...@lists.alioth.debian.org>
user-he
Debian IRC Team <pkg-irc-m...@lists.alioth.debian.org>
atheme-services
Debian Java Maintainers <pkg-java-m...@lists.alioth.debian.org>
maven2
tomcat5.5
Debian KDE Extras Team <pkg-kde...@lists.alioth.debian.org>
kdebluetooth
Debian Live <debian-l...@lists.alioth.debian.org>
live-initramfs
Debian Loop-AES Team <pkg-loop-...@lists.alioth.debian.org>
loop-aes-utils
Debian Mono Group <pkg-mon...@lists.alioth.debian.org>
mono-1.0-devel
Debian OCaml Maintainers <debian-oc...@lists.debian.org>
camlp5
ocaml-mode
Debian Qt/KDE Maintainers <debian...@lists.debian.org>
kdesdk-scripts
kexi
kopete
Debian surfraw maintainers <surfra...@lists.alioth.debian.org>
surfraw
Debian sysvinit maintainers <pkg-sysvi...@lists.alioth.debian.org>
sysv-rc
Debian TeX Maintainers <debian-t...@lists.debian.org>
texlive-base-bin
texlive-extra-utils
Debian TeX maintainers <debian-t...@lists.debian.org>
texinfo
Debian VDR Team <pkg-vdr-...@lists.alioth.debian.org>
nvram-wakeup
Debian Virtualbox Team <pkg-virtua...@lists.alioth.debian.org>
virtualbox-ose
Debian VoIP Team <pkg-voip-m...@lists.alioth.debian.org>
bayonne
openser
ser
Debian Xfce Maintainers <pkg-xfc...@lists.alioth.debian.org>
xfce4-dev-tools
Debian XML/SGML Group <debian-xml...@lists.alioth.debian.org>
docbook-utils
docbook2x
Debian-Med Packaging Team <debian-med...@lists.alioth.debian.org>
minc-tools
Eric Delaunay <dela...@debian.org>
scsitools
Grzegorz Prokopski (Debian Developer) <ga...@debian.org>
free-java-sdk
Yann Dirson <dir...@debian.org>
libtulip-3.0-dev
stgit-contrib (U)
Mattia Dongili <mala...@debian.org>
cpufrequtils
Sebastian Dröge <sl...@debian.org>
mono-1.0-devel (U)
Dirk Eddelbuettel <e...@debian.org>
munge (U)
Peter Eisentraut <pet...@debian.org>
apt-rpm-repository
licq
Zak B. Elep <zak...@spunge.org>
cvs (U)
Carey Evans <ca...@debian.org>
tn5250
Baruch Even <bar...@debian.org>
user-he (U)
Exim4 Maintainers <pkg-exim4-...@lists.alioth.debian.org>
exim4-base
Peter Van Eynde <pvan...@debian.org>
cl-launch (U)
Fabian Fagerholm <fa...@debian.org>
sasl2-bin (U)
Khalid El Fathi <inv...@edena-fr.org>
gjots2
Bartosz Fenski <fe...@debian.org>
msort-gui
redet
Laurent Fousse <lau...@komite.net>
megahal
dann frazier <da...@debian.org>
systemimager-server
Jochen Friedrich <joc...@scram.de>
libsnmp-base (U)
Sylvain Le Gall <gil...@debian.org>
ocaml-mode (U)
Luigi Gangitano <lu...@debian.org>
sarg
Bdale Garbee <bd...@gag.com>
amanda-server
Ionut Georgescu <geo...@pks.mpg.de>
grace
grace6
Daniel Kahn Gillmor <dkg-deb...@fifthhorseman.net>
vblade-persist
Kevin Glynn <gl...@info.ucl.ac.be>
mozart-stdlib
GNU/kFreeBSD Maintainers <debia...@lists.debian.org>
freebsd-sendpr
Martin A. Godisch <god...@debian.org>
minicom
Rudy Godoy <ru...@kernel-panik.org>
xfce4-dev-tools (U)
Thomas Goirand <tho...@goirand.fr>
dtc-xen
Matthew Grant <gra...@anathoth.gen.nz>
netscript-2.4
Andreas "Jimmy" Gredler <ji...@g-tec.co.at>
gcom
Tobias Grimm <t...@e-tobi.net>
nvram-wakeup (U)
Debian QA Group <pack...@qa.debian.org>
cvsdelta
flowscan
gnome-bin
metamail
mknfonts.tool
secpanel
sn
varkon
vflib3-bin
Grub Maintainers <pkg-gru...@lists.alioth.debian.org>
grub
Marc Haber <mh+debian...@zugschlus.de>
exim4-base (U)
torrus-common (U)
Wartan Hachaturow <wa...@softhome.net>
console-common (U)
Pascal Hakim <pa...@debian.org>
snort (U)
snort-mysql (U)
snort-pgsql (U)
Yaroslav Halchenko <deb...@onerussian.com>
fail2ban
Chris Hanson <c...@debian.org>
xdeview
Tollef Fog Heen <tfh...@debian.org>
root-portal
Eric Heintzmann <er...@gnustep.fr.st>
gnustep-common (U)
gnustep-make-ogo (U)
Andreas Henriksson <and...@fatal.se>
bandwidthd-pgsql
Andres Seco Hernandez <Andr...@debian.org>
alamin-server
Robert D. Hilliard <hill...@debian.org>
dict (U)
dictfmt (U)
Sarah Hobbs <hob...@ubuntu.com>
kopete (U)
Henrique de Moraes Holschuh <h...@debian.org>
sysv-rc (U)
Simon Horman <ho...@debian.org>
heartbeat
Philipp Hug <deb...@hug.cx>
iscsitarget
virtualbox-ose (U)
Simon Huggins <hug...@earth.li>
xfce4-dev-tools (U)
Mario Iseli <ma...@debian.org>
atheme-services (U)
Ian Jackson <i...@chiark.greenend.org.uk>
sauce
Jan Janak <j...@iptel.org>
ser (U)
Aurelien Jarno <aur...@debian.org>
freebsd-sendpr (U)
gcc-m68hc1x
Joerg Jaspert <jo...@debian.org>
vlock (U)
Steffen Joeris <wh...@debian.org>
foo2zjs (U)
Guillem Jover <gui...@debian.org>
freebsd-sendpr (U)
Ove Kaaven <ov...@arcticnet.no>
wine-bin
Kurt B. Kaiser <k...@shore.net>
nana
Panu Kalliokoski <ate...@sange.fi>
stx2any
Lior Kaplan <kap...@debian.org>
user-he (U)
Simon Kelley <si...@thekelleys.org.uk>
brag
Steve Kemp <s...@debian.org>
xen-shell (U)
Julian Andres Klode <j...@jak-linux.org>
aufs-tools
Matthias Klose <do...@debian.org>
bash
gcc-3.3 (U)
gcc-3.4 (U)
gcc-4.1 (U)
isdnvboxclient (U)
Michael Koch <konq...@gmx.de>
foo2zjs (U)
tomcat5.5 (U)
Atsuhito KOHDA <ko...@debian.org>
ptex-jtex
martin f. krafft <mad...@debian.org>
fluxbox (U)
hibernate
Kilian Krause <kil...@debian.org>
bayonne (U)
openser (U)
ser (U)
Anand Kumria <wild...@progsoc.org>
stgit-contrib
stgit-contrib (U)
Arnaud Kyheng <Arnaud...@free.fr>
gnunet-client
Frank Küster <fr...@debian.org>
texinfo (U)
texlive-base-bin (U)
texlive-extra-utils (U)
Rafael Laboissiere <raf...@debian.org>
docbook2x (U)
Corrin Lakeland <lake...@debian.org>
visual-regexp
Ron Lee <r...@debian.org>
mingw32
Yven Johannes Leist <le...@beldesign.de>
phpix
Jeff Licquia <lic...@debian.org>
diald
Chuan-kai Lin <ck...@debian.org>
apt-move
Andre Luis Lopes <andr...@debian.org>
ibackup
Ana Beatriz Guerrero Lopez <a...@debian.org>
kdesdk-scripts (U)
kexi (U)
kopete (U)
Martin Loschwitz <mad...@debian.org>
xfce4-dev-tools (U)
Robert Luberda <rob...@debian.org>
dict
dictfmt
isag
Ola Lundqvist <op...@debian.org>
cron-apt
dpsyco-base
siege (U)
tightvnc-java
vzctl
Sven Luther <lut...@debian.org>
ocaml-mode (U)
Ian Maclaine-cross <i...@debian.org>
ddns3-client
Mikael Magnusson <mi...@users.sourceforge.net>
ld10k1 (U)
Dovecot Maintainers <jaldhar...@debian.org>
dovecot-common
Jordi Mallach <jo...@debian.org>
gtranslator
ld10k1 (U)
minicom (U)
Santiago Garcia Mantinan <ma...@debian.org>
bayonne (U)
Christian Marillat <mari...@debian.org>
zapping
Christoph Martin <christop...@uni-mainz.de>
mimedefang
Christopher Martin <chrs...@debian.org>
kopete (U)
Daniel Martin <fiz...@debian.org>
tkdesk
Paul Martin <p...@debian.org>
radioclk
Rene Mayorga <rmay...@debian.org.sv>
afbackup
afbackup-client
Rene Mayrhofer <rm...@debian.org>
strongswan
Kevin B. McCarty <kmcc...@debian.org>
paw-demos
Jonathan McDowell <noo...@earth.li>
remote-tty
Steve McIntyre <93...@debian.org>
cvs
netpbm (U)
Alastair McKinstry <mcki...@debian.org>
console-common
console-tools
ltp
Jose Carlos Medeiros <deb...@psabs.com.br>
siege
Christian Meder <ch...@absolutegiganten.org>
aegis-tk
Remco van de Meent <re...@debian.org>
libsmi2
Michael Meskes <mes...@debian.org>
kdebluetooth (U)
netdiag
virtualbox-ose (U)
Andreas Metzler <amet...@debian.org>
exim4-base (U)
Josh Metzler <jos...@metzlers.org>
kdesdk-scripts (U)
Jonas Meurer <me...@debian.org>
cryptsetup (U)
lurker
Robert Millan <r...@debian.org>
grub (U)
Raul Miller <mo...@debian.org>
debmake (U)
Samuel Mimram <smi...@debian.org>
ocaml-mode (U)
Loic Minier <lo...@dooz.org>
gtranslator (U)
Hamish Moffatt <ham...@debian.org>
ax25-tools (U)
hf (U)
libguilegtk-1.2-dev
David Martínez Moreno <en...@debian.org>
k3d
Moritz Muehlenhoff <j...@debian.org>
surfraw (U)
Ramakrishnan Muthukrishnan <rkri...@debian.org>
ax25-tools (U)
Net-SNMP Packaging Team <pkg-net-s...@lists.alioth.debian.org>
libsnmp-base
Jaakko Niemi <li...@debian.org>
sfs-client
Dmitry E. Oboukhov <di...@avanto.org>
fluxbox
Recai Oktaş <rok...@debian.org>
pandoc
Gennaro Oliva <oli...@na.icar.cnr.it>
munge
Patrick Ouellette <pou...@debian.org>
ax25-tools (U)
hf (U)
Marcin Owsiany <porr...@debian.org>
ekg
Sam Hocevar (Debian packages) <sam...@zoy.org>
allegro-examples (U)
libalogg-dev (U)
Peter Palfrader <wea...@debian.org>
vlock (U)
Gerrit Pape <pa...@smarden.org>
cfs
git-core
git-gui
gitk
Luca Pasquali <lu...@sadlands.org>
fwanalog (U)
Cameron Patrick <cam...@patrick.wattle.id.au>
hibernate (U)
Andrei Pelinescu-Onciul <and...@iptel.org>
ser (U)
Javier Fernandez-Sanguino Pen~a <j...@debian.org>
bastille
jailer
nessus-plugins
snort
snort-mysql
snort-pgsql
Yves-Alexis Perez <cor...@corsac.net>
xfce4-dev-tools (U)
Christian Perrier <bub...@debian.org>
console-common (U)
Ben Pfaff <pfaf...@debian.org>
autoconf2.13
Brandon Philips <bra...@ifup.org>
guilt
Michael Piefel <pie...@debian.org>
tkinfo
Alexandre Pineau <alexandr...@free.fr>
libalogg-dev (U)
William Pitcock <nen...@sacredspiral.co.uk>
atheme-services (U)
Cajus Pollmeier <ca...@debian.org>
gosa-desktop
Norbert Preining <prei...@debian.org>
texinfo (U)
texlive-base-bin (U)
texlive-extra-utils (U)
Mark Purcell <m...@debian.org>
bayonne (U)
gsm-utils
kdebluetooth (U)
ser (U)
Andreas Putzo <and...@putzo.net>
gpsdrive-scripts (U)
Angel Ramos <sea...@debian.org>
knetfilter
Ardo van Rangelrooij <ar...@debian.org>
docbook-utils (U)
docbook2x (U)
Petter Reinholdtsen <pe...@debian.org>
sysv-rc (U)
Simon Richter <s...@debian.org>
bayonne (U)
Francois-Rene Rideau <fa...@tunes.org>
cl-launch
Elimar Riesebieter <ries...@lxtec.de>
ld10k1 (U)
Steve M. Robbins <s...@debian.org>
dirdiff
minc-tools (U)
Jaime Robles <ja...@debian.org>
ax25-tools (U)
hf (U)
Emanuele Rocca <e...@debian.org>
fwanalog
fwanalog (U)
xfce4-dev-tools (U)
José L. Redrejo Rodríguez <jred...@debian.org>
freehdl
Kurt Roeckx <ku...@roeckx.be>
libtool
Roland Rosenfeld <rol...@debian.org>
ding
lbdb
transfig
Peter van Rossum <pet...@debian.org>
scid
Ludovic Rousseau <rous...@debian.org>
plucker
Giuseppe Sacco <eppe...@debian.org>
hylafax-server
Anibal Monsalve Salazar <ani...@debian.org>
antiword
Otavio Salvador <ota...@debian.org>
grub (U)
Roberto C. Sanchez <rob...@connexer.com>
sasl2-bin (U)
shorewall-common
shorewall-lite
webcpp
Thomas Schmidt <tsch...@debian.org>
nvram-wakeup (U)
Bernd Schumacher <bernd.sc...@hp.com>
bootcd
secvpn
Frederik Schüler <f...@debian.org>
iscsitarget (U)
Shachar Shemesh <sha...@debian.org>
user-he (U)
Alejandro Sierra <algs...@gmail.com>
libvigraimpex-dev
Paul Slootman <pa...@debian.org>
isdnvboxclient
isdnvboxclient (U)
wwwoffle
Jurij Smakov <ju...@debian.org>
torrus-common (U)
Jonas Smedegaard <d...@jones.dk>
sdm
Thomas Smith <t...@debian.org>
surfraw (U)
Miquel van Smoorenburg <miq...@cistron.nl>
sysv-rc (U)
Jose Carlos Garcia Sogo <js...@debian.org>
bayonne (U)
beagle (U)
Radu Spineanu <ra...@debian.org>
pvpgn
xen-shell
xmail
Manoj Srivastava <sriv...@debian.org>
polgen
slat
tla-tools
Joop Stakenborg <pa3...@debian.org>
antennavis
ax25-tools (U)
hf (U)
Marvin Stark <ma...@der-marv.de>
virtualbox-ose (U)
Fredrik Steen <st...@debian.org>
txt2man
Roland Stigge <sti...@antcom.de>
etktab
rgpsp
Al Stone <ah...@debian.org>
oprofile
ski (U)
Christian Surchi <csu...@debian.org>
surfraw (U)
Sergio Talens-Oliag <s...@debian.org>
ssft
Michael Tautschnig <m...@debian.org>
lnpd
Jason Thomas <ja...@debian.org>
grub (U)
Andreas Tille <ti...@debian.org>
wordnet
Gerhard Tonn <g...@debian.org>
gcc-3.3 (U)
gcc-3.4 (U)
Torrus maintainers <pkg-torrus-...@lists.alioth.debian.org>
torrus-common
Fabio Tranchitella <kob...@debian.org>
dovecot-common (U)
James Troup <ja...@nocrew.org>
gawk
Francis Tyers <fty...@prompsit.com>
apertium
Fumitoshi UKAI <uk...@debian.or.jp>
auto-apt
groff (U)
groff-base (U)
Luis Uribe <ac...@eviled.org>
autolog
Modestas Vainius <gero...@mailas.com>
kopete (U)
Julien Valroff <jul...@kirya.net>
rkhunter (U)
Arnaud Vandyck <av...@debian.org>
tomcat5.5 (U)
Santiago Vila <san...@debian.org>
debmake
debmake (U)
gettext
gettext-base
Max Vozeler <x...@debian.org>
loop-aes-utils (U)
Sune Vuorela <deb...@pusling.com>
kdesdk-scripts (U)
kopete (U)
Jaldhar H. Vyas <jal...@debian.org>
dovecot-common (U)
Daniel Walrond <deb...@djw.org.uk>
mlmmj
Chad Walstrom <che...@debian.org>
gnats-user
Colin Watson <cjwa...@debian.org>
groff
groff-base
Florian Weimer <f...@deneb.enyo.de>
xml2rfc
Torsten Werner <twe...@debian.org>
afbackup (U)
afbackup-client (U)
grace (U)
grace6 (U)
Ian Wienand <ia...@debian.org>
ski
Patrick Winnertz <win...@debian.org>
virtualbox-ose (U)
Alexander Wirt <form...@debian.org>
vlock
Paweł Więcek <co...@debian.org>
slay
Alan Woodland <awoo...@debian.org>
ogle
ogle-mmx
Wookey <woo...@debian.org>
therion
Oohara Yuuma <ooh...@debian.org>
mpatrolc2
Stefano Zacchiroli <za...@debian.org>
camlp5 (U)
ocaml-mode (U)
James R. Van Zandt <j...@debian.org>
adjtimex
emacspeak
Bernd Zeimetz <be...@bzed.de>
radiance
Anton Zinoviev <zino...@debian.org>
kbd (U)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHn9myYy49rUbZzloRAlCaAJsEiUnpL+LeK+iuYgC4AgyUBzmA/wCfbF6b
jLHDm6QU6KdgZbndzJaTqFo=
=l/9b
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Wise
> 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.
Has there been any bashisms checks on maintainer scripts (postinst/etc)?
I really really think we need a way to integrate these myriad QA
checks into the PTS and DDPO and the page I proposed in #461898.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Cyril Brulebois
> Has there been any bashisms checks on maintainer scripts (postinst/etc)?
There's already:
http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html
Cheers,
--
Cyril Brulebois
Raphael Geissert
> On 30/01/2008, Paul Wise wrote:
>> Has there been any bashisms checks on maintainer scripts (postinst/etc)?
>
> There's already:
>
http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html
And as for debian/rules Lucas Nussbaum rebuilt the archive with dash
as /bin/sh :)
>
> Cheers,
>
Cheers,
Raphael Geissert
Raphael Geissert
>
> I really really think we need a way to integrate these myriad QA
> checks into the PTS and DDPO and the page I proposed in #461898.
>
I'm going to generate a BDB with the information from the lintian test on
amd64 as soon as I find some time for it and somewhere to place it :)
P.D. how is mole used by the way?
Cheers,
Raphael Geissert
Steffen Grunewald
>
> [Please only reply to -devel]
Reply-To?
> 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.
I suppose it would also be useful to check {post,pre}{inst,rm} scripts?
Steffen
--
Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * http://pandora.aei.mpg.de/merlin/ * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html
Stefano Zacchiroli
> camlp5 (U)
This is a false positive:
$ checkbashisms /usr/bin/mkcamlp5
possible bashism in /usr/bin/mkcamlp5 line 43 (let ...):
echo "let _ = Dynlink.add_available_units crc_unit_list" >> $CRC.ml
checkbashisms is complaining about the "let", which is part of a string
which is being outputed, not a line of shell script which will be
executed.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the
(15:57:15) Bac: no, la demo scema \/ right keys at the right time
Paul Wise
<cyril.b...@enst-bretagne.fr> wrote:
> On 30/01/2008, Paul Wise wrote:
> > Has there been any bashisms checks on maintainer scripts (postinst/etc)?
>
> There's already:
> http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html
Ah, so there is.
There doesn't seem to be a lintian check for what Raphael has checked
for though.
Raphael, perhaps you could submit a bug+patch to lintian if you haven't already?
Ben Finney
> On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
> >
> > [Please only reply to -devel]
>
> Reply-To?
That's a field defined (in RFC 2822) as specifying where posts
intended individually to the author ("replies") should be sent. It
would not be good to have such replies sent instead to a public
mailing list.
I suspect Raphael instead wants to specify that public follow-up posts
(not individual replies) should go to debian-devel. The
Mail-Followup-To field is often used for this, but is not a standard
nor widely implemented.
--
\ "Sunday School: A prison in which children do penance for the |
`\ evil conscience of their parents." -- Henry L. Mencken |
_o__) |
Ben Finney
Hamish Moffatt
Thanks, fixed these two.
> libguilegtk-1.2-dev
False alarm: the /usr/bin/build-gtk-guile script is actually in guile,
but has a quick shell wrapper at the top. checkbashisms is fooled.
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Raphael Geissert
>
> There doesn't seem to be a lintian check for what Raphael has checked
> for though.
> Raphael, perhaps you could submit a bug+patch to lintian if you haven't
> already?
>
If there's any chance to get it in lintian it'd be great.
I haven't sent any bug/patch for it, hope Russ (or any lintian maintainer)
checks this thread and give his opinion.
The script basically uses find on those directories (under /usr/share it
only searches for '*.sh') and then uses file on those to get a new list of
those file being shell scripts which are then checked with checkbashisms.
Cheers,
Raphael Geissert
Rene Mayorga
>
> Rene Mayorga <rmay...@debian.org.sv>
> afbackup
> afbackup-client
False positive
Both one have csh scripts.
Cheers
--
Rene Mauricio Mayorga
Raphael Geissert
> Steffen Grunewald <steffen....@aei.mpg.de> writes:
>
>> On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
>> >
>> > [Please only reply to -devel]
>>
>> Reply-To?
I sent the email via KNode/gmane, AFAIR there's no way to set a Reply-To.
>
> That's a field defined (in RFC 2822) as specifying where posts
> intended individually to the author ("replies") should be sent. It
> would not be good to have such replies sent instead to a public
> mailing list.
>
> I suspect Raphael instead wants to specify that public follow-up posts
> (not individual replies) should go to debian-devel. The
> Mail-Followup-To field is often used for this, but is not a standard
> nor widely implemented.
>
I did set the following header but seems like gmane didn't convert it when
finally sending the email (I'm not even sure if it is supposed to do so):
Followup-To: gmane.linux.debian.devel.general
And yes, it was a way to say "don't reply neither to -release nor my email
address, only to -devel".
Cheers,
Raphael Geissert
Luis Rodrigo Gallardo Cruz
> On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
> > libguilegtk-1.2-dev
>
> False alarm: the /usr/bin/build-gtk-guile script is actually in guile,
> but has a quick shell wrapper at the top. checkbashisms is fooled.
Same case for /usr/bin/sawfish-client in sawfish.
Is there some quick way this kind of thing could be detected?
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
Raphael Geissert
Version: 2.10.13
User: devsc...@packages.debian.org
Usertags: checkbashisms
Luis Rodrigo Gallardo Cruz wrote:
> On Wed, Jan 30, 2008 at 11:49:23PM +1100, Hamish Moffatt wrote:
>> On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
>> > libguilegtk-1.2-dev
>>
>> False alarm: the /usr/bin/build-gtk-guile script is actually in guile,
>> but has a quick shell wrapper at the top. checkbashisms is fooled.
>
> Same case for /usr/bin/sawfish-client in sawfish.
>
> Is there some quick way this kind of thing could be detected?
>
This sounds more like a report against checkbashisms.
I guess it could try to detect these:
> exec guile -s $0 $*
> !#
> exec rep "$0" "$@"
> !#;; Source file: sawfish-client.jl
By the way, why don't just use a shebang like #!/usr/bin/guile ?
Cheers,
Raphael Geissert
Russ Allbery
> This is a false positive:
>
> $ checkbashisms /usr/bin/mkcamlp5
> possible bashism in /usr/bin/mkcamlp5 line 43 (let ...):
> echo "let _ = Dynlink.add_available_units crc_unit_list" >> $CRC.ml
>
> checkbashisms is complaining about the "let", which is part of a string
> which is being outputed, not a line of shell script which will be
> executed.
checkbashisms should be updated to use the current code in lintian, which
(more) correctly handles quoted strings (and heredocs and various other
similar complications).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery
> This sounds more like a report against checkbashisms.
> I guess it could try to detect these:
See script_is_evil_and_wrong() in lintian's check/scripts.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery
> Paul Wise wrote:
>> There doesn't seem to be a lintian check for what Raphael has checked
>> for though. Raphael, perhaps you could submit a bug+patch to lintian
>> if you haven't already?
It's been a wishlist bug in lintian for eons. What needs to happen from
the lintian perspective is to refactor check/scripts to pull the code for
checking for bashisms into a module, and then apply that same code to
check other shell scripts and to the (detabbed) shell constructs in
debian/rules. Getting the interface to the module right may be a little
tricky.
> The script basically uses find on those directories (under /usr/share it
> only searches for '*.sh') and then uses file on those to get a new list
> of those file being shell scripts which are then checked with
> checkbashisms.
lintian shouldn't depend on checkbashisms. It already has its own
implementation of this code (which from this thread is actually better).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Raphael Geissert
> Raphael Geissert <atomo64...@gmail.com> writes:
>
>> This sounds more like a report against checkbashisms.
>> I guess it could try to detect these:
>
> See script_is_evil_and_wrong() in lintian's check/scripts.
>
Based on the next statement on checkbashisms I though they were kept in
sync:
> # This script is essentially copied
from /usr/share/lintian/checks/scripts,
Cheers,
Raphael Geissert
Raphael Geissert
Thanks Russ for your input.
Russ Allbery wrote:
> Raphael Geissert <atomo64...@gmail.com> writes:
>> The script basically uses find on those directories (under /usr/share it
>> only searches for '*.sh') and then uses file on those to get a new list
>> of those file being shell scripts which are then checked with
>> checkbashisms.
>
> lintian shouldn't depend on checkbashisms. It already has its own
> implementation of this code (which from this thread is actually better).
>
I know, I just explained how my script works.
It'd be nice if lintian could provide an interface to perform an specific
check on a specific file (not on a .deb directly). That's out of lintian's
pourpose but it would be nice anyway.
Cheers,
Raphael Geissert
Adam D. Barratt
> Russ Allbery wrote:
>
> > Raphael Geissert <atomo64...@gmail.com> writes:
> >
> >> This sounds more like a report against checkbashisms.
> >> I guess it could try to detect these:
> >
> > See script_is_evil_and_wrong() in lintian's check/scripts.
> >
>
> Based on the next statement on checkbashisms I though they were kept in
> sync:
>
> > # This script is essentially copied
> from /usr/share/lintian/checks/scripts,
It should probably say "was", rather than "is". That said, I'll have a
look at updating checkbashisms's parsing code in line with lintian's
(probably over the weekend).
Adam
Russ Allbery
> It'd be nice if lintian could provide an interface to perform an
> specific check on a specific file (not on a .deb directly). That's out
> of lintian's pourpose but it would be nice anyway.
One of my long-term goals for lintian is to move more of the mechanics of
checks like this into Perl modules and ideally install those modules into
the regular Perl module path (while still supporting --root, of course).
Then, checkbashisms could just depend on lintian and use the same code.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Adam D. Barratt
> Raphael Geissert <atomo64...@gmail.com> writes:
> > The script basically uses find on those directories (under /usr/share it
> > only searches for '*.sh') and then uses file on those to get a new list
> > of those file being shell scripts which are then checked with
> > checkbashisms.
>
> lintian shouldn't depend on checkbashisms. It already has its own
> implementation of this code (which from this thread is actually better).
lintian's parsing code certainly sounds better (mainly because
checkbashisms is based on an old version of the lintian code) but, from
a quick look, checkbashisms flags more issues than lintian does. We do
appear to be missing a few though; I'll have a look at getting them back
in sync.
Adam (with devscripts hat on)
Russ Allbery
> lintian's parsing code certainly sounds better (mainly because
> checkbashisms is based on an old version of the lintian code) but, from
> a quick look, checkbashisms flags more issues than lintian does. We do
> appear to be missing a few though; I'll have a look at getting them back
> in sync.
I'd definitely welcome any additional regexes or code to add to lintian.
(And at some point we can figure out how to keep this in sync with less
effort.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Kevin B. McCarty
> Kevin B. McCarty <kmcc...@debian.org>
> paw-demos
This is a false positive:
% checkbashisms bin/paw-demos.in
possible bashism in bin/paw-demos.in line 54 ('select' is not POSIX):
echo "(Or use the --dir option to the script to select a different"
best regards,
--
Kevin B. McCarty <kmcc...@gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
Petter Reinholdtsen
Probably false alarm, as it has been successfully used on systems with
dash as /bin/sh. Please report a bug with the details if it still got
bashism.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
Raphael Geissert
>
> 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-dev...@lists.debian.org
Petter Reinholdtsen
[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-rele...@lists.debian.org
Bernd Zeimetz
> 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
<be...@bzed.de> <http://bzed.de/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Ralf Wildenhues
> 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
Raphael Geissert
Ralf Wildenhues wrote:
>> Kurt Roeckx <ku...@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
Russ Allbery
> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ben Pfaff
> 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
Ben Pfaff
> 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
Russ Allbery
>> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
Clint Adams
> 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.
Since 0.5.6, it does not; the only number it understands is the
pseudo-signal 0, mandated by POSIX.
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.
When the names are used, this confusion is avoided.
Russ Allbery
> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ben Pfaff
> On Sat, Feb 09, 2008 at 04:39:11PM -0800, Russ Allbery wrote:
>> 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.
>
> Since 0.5.6, it does not; the only number it understands is the
> pseudo-signal 0, mandated by POSIX.
>
> 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.
The XSI option to SUSv3 does not say that numeric signal numbers
are interpreted in a system-specific way. It is very specific
that numeric 1 is SIGHUP, 2 is SIGINT, 3 is SIGQUIT, 6 is
SIGABRT, 9 is SIGKILL, 14 is SIGALRM, and 15 is SIGTERM:
http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
--
Ben Pfaff
http://benpfaff.org
Raphael Geissert
> Clint Adams <sch...@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.
>
So should I only ignore those specifying a signal number in the 1-15 range?
Cheers,
Raphael Geissert
Raphael Geissert
> Raphael Geissert <atomo64...@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.
At the moment I'm not filling reports for packages shipping /bin/sh scripts
for which checkbashisms only complains about trap/kill with signal number.
Cheers,
Raphael
Ben Pfaff
> Russ Allbery wrote:
>
>> Clint Adams <sch...@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.
>>
>
> So should I only ignore those specifying a signal number in the 1-15 range?
I'd suggest complaining about those that specify numbers other
than 0, 1, 2, 3, 6, 9, 14, or 15. See
http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
--
Ben Pfaff
http://benpfaff.org
Ralf Wildenhues
* 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
Ralf Wildenhues
> I'd suggest complaining about those that specify numbers other
> than 0, 1, 2, 3, 6, 9, 14, or 15. See
> http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
Is there any system where 13 is not SIGPIPE? I don't know of one, it's
documented in the Autoconf manual as portable, it's used by all
autoconf-generated configure scripts out there, I've never heard any
problems with it. It would be hilarious if Debian were the only system
not to support this usage.
BTW, no matter what POSIX says, named signals are not portable to
pre-POSIX shells, which is why Autoconf and Libtool do not use them.
Cheers,
Ralf
Hendrik Sattler
> BTW, no matter what POSIX says, named signals are not portable to
> pre-POSIX shells, which is why Autoconf and Libtool do not use them.
POSIX may not apply to pre-POSIX shells. So what?
Creating a standard is not always a method to documenting the current way of
doing things. Thus, implementations before the standard can differ from it.
At one point you have to go on and ignore ancient systems.
HS
Adam D. Barratt
> Raphael Geissert <atomo64...@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.
That check was recently added during the lintian <-> checkbashisms sync.
If the feeling is that its incorrect, it should probably be removed from
lintian as well.
Adam
Adam D. Barratt
> Raphael Geissert <atomo64...@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.
In hindsight, checkbashisms may not have been the best name for the
script, but checkscriptcompliestosus isn't quite as catchy. :-)
I'm debating adding an option to ignore XSI-isms when checking scripts.
However, I will add that a) the check is also in lintian, albeit only
for maintainer scripts and b) so far as I can see, using it in scripts
with a /bin/sh shebang is technically a policy violation, even if not
one that people care about.
Adam
Roberto C. Sánchez
>
> Roberto C. Sanchez <rob...@connexer.com>
> sasl2-bin (U)
This will be handled by the Cyrus-SASL team.
> shorewall-common
> shorewall-lite
These two are false positives.
> webcpp
This one I am investigating and hope to have an upload ready soon.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com