Re: RFH: bashisms in configure script
On 2010-05-26 00:18:23 +0200, David Weinehall wrote: You're getting things the wrong way around. The version of dash that will be put in experimental will be the correct one, the one in unstable will be the crippled one. The reason things fails isn't because of dash, but because of sloppy programming on behalf of people that still believe that bash is the say all and end all when it comes to shell scripts. The problem is not programmers, but the system. It is well-known that programmers make mistakes (FYI, == also comes from C/csh so that it is easy to be wrong), and testing allows one to discover such mistakes. But for that, one needs a POSIX-compliant /bin/sh with no extensions. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529123206.ga15...@prunille.vinc17.org
Re: RFH: bashisms in configure script
Stefan Fritsch wrote: On Tuesday 25 May 2010, Raphael Geissert wrote: 1. If your name is on the list at [2] please check at [3] the .dsc file that corresponds to the source packages you co-/maintain, review and fix. The .dsc files contain checkbashisms' output. Do you want to start a list with errors that can be ignored because they are in unused scripts? Yes. I don't know how/where, but it sounds like a good idea. [...] Since srclib/pcre/configure is never executed during the build of the Debian package, I don't see any value in fixing it. Sure, that's ok, but please don't forget to report it upstream. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/htpksj$3t...@dough.gmane.org
Re: RFH: bashisms in configure script
On Wed, May 26, 2010 at 08:05:32AM +0200, Lucas Nussbaum wrote: I'm still feeling uneasy about this whole bash-dash thing. We sacrified a lot of usability in the name of POSIX compliance (only a minority of users care) and a few seconds spared during boot (who cares? I only boot my laptop for kernel upgrades). boot? It's hardly because of boot, it's mostly because of scripts that keep getting run on your system all the time. They make up ~16% of files in /usr/bin/, and, unlike programs in other languages, they tend to be very short-lived and thus get started a lot. And shell is not just for proper separate-file scripts. Let's glance at what gets done during a build: │ ├─sshd───sshd───bash───make───5*[sh───x86_64-linux-gn─┬─as] │ │ └─cc1plus] You have a separate bash/dash/posh process for every single command run by make. With bash's insane startup time, that makes a significant difference. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527152458.ga26...@angband.pl
Re: RFH: bashisms in configure script
On Tuesday 25 May 2010, Raphael Geissert wrote: 1. If your name is on the list at [2] please check at [3] the .dsc file that corresponds to the source packages you co-/maintain, review and fix. The .dsc files contain checkbashisms' output. Do you want to start a list with errors that can be ignored because they are in unused scripts? For example in apache2: possible bashism in ./srclib/pcre/configure line 3915 (should be 'b = a'): enableval=$enable_ebcdic; if test $enableval == yes; then Since srclib/pcre/configure is never executed during the build of the Debian package, I don't see any value in fixing it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005272241.57985...@sfritsch.de
Re: RFH: bashisms in configure script
Hi, I'm still feeling uneasy about this whole bash-dash thing. We sacrified a lot of usability in the name of POSIX compliance (only a minority of users care) and a few seconds spared during boot (who cares? I only boot my laptop for kernel upgrades). Was is really the right path to follow? Wouldn't it have been easier to work on bash to make sure that it supports everything POSIX requires, and to improve its performance a bit? Now we are going to patch configure scripts to make sure that they can run correctly with dash. What's next? Rewrite C programs that use GCC-specific extensions? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526060532.ga9...@xanadu.blop.info
Re: RFH: bashisms in configure script
On 25/05/10 at 23:10 +0100, Neil Williams wrote: On Tue, 25 May 2010 16:13:36 -0500 Raphael Geissert geiss...@debian.org wrote: A much more sane list is in the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) No. 124 is the number of packages that failed to build. Not the number of source packages that silently generated incorrect binary packages. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526060740.gb9...@xanadu.blop.info
Re: RFH: bashisms in configure script
On Tue, 25 May 2010, Peter Samuelson wrote:
And more false positives:
possible bashism in ./configure line 44 ($BASH_SOMETHING):
if test -z $BASH_VERSION$ZSH_VERSION \
(test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
possible bashism in ./configure line 367 (should be word 21):
$as_echo $as_me:${as_lineno-$LINENO}: error: $1 $3
Both were produced by autoconf 2.65.
First is a false positive for the same reason Kurt's example is.
Second is a false positive because $3 in this instance is a numbered
file descriptor.
Same goes for dpkg, it only has those two warnings.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526062150.ga16...@rivendell
Re: RFH: bashisms in configure script
On 05/26/2010 08:05 AM, Lucas Nussbaum wrote: Hi, I'm still feeling uneasy about this whole bash-dash thing. We sacrified a lot of usability in the name of POSIX compliance (only a minority of users care) and a few seconds spared during boot (who cares? I only boot my laptop for kernel upgrades). Many desktop users boot regulary, besides if you have a difficult to reach SLA, it's nice to have a fast boot... Was is really the right path to follow? Wouldn't it have been easier to work on bash to make sure that it supports everything POSIX requires, and to improve its performance a bit? Now we are going to patch configure scripts to make sure that they can run correctly with dash. What's next? Rewrite C programs that use GCC-specific extensions? Making sure they run correctly with dash is one solution, making sure they run with bash is another one... Regarding C, that's kind of happening with gcc becoming more and more compliant with the standard... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfcbf41.5060...@debian.org
Re: RFH: bashisms in configure script
On mar., 2010-05-25 at 19:35 -0500, Raphael Geissert wrote:
./configure is a *generated* script too, if dash cannot handle it, dash
has to be crippled to let the other packages continue working. Unless
autoconf itself has already been patched to fix all of these issues when
regenerating ./configure from configure.ac, all this would be a waste
of effort anyway.
It is not about whether dash can handle it or not. The bashisms don't come
from autoconf, the come from what the author's added to configure.in{,.in}.
I beg to differ, at least some of them don't come from configure.*. One
example is
http://people.debian.org/~geissert/source-bashisms/evolution_2.30.1.2-2.dsc
where I can't really fine the $3 call (nor any for that matter) in the
configure.* files.
And here, just a quick test shown that:
cor...@hidalgo: grep -c '' /usr/share/*/config.{guess,sub}
/usr/share/automake-1.11/config.guess:13
/usr/share/automake-1.7/config.guess:13
/usr/share/misc/config.guess:13
/usr/share/automake-1.11/config.sub:5
/usr/share/automake-1.7/config.sub:5
/usr/share/misc/config.sub:5
cor...@hidalgo: dpkg -S /usr/share/*/config.{guess,sub}
automake: /usr/share/automake-1.11/config.guess
automake1.7: /usr/share/automake-1.7/config.guess
autotools-dev: /usr/share/misc/config.guess
automake: /usr/share/automake-1.11/config.sub
automake1.7: /usr/share/automake-1.7/config.sub
autotools-dev: /usr/share/misc/config.sub
Interestingly, they don't seem to be caught by checkbashisms (maybe I
still have a non working version?)
cor...@hidalgo: checkbashisms /usr/share/*/config.{guess,sub}
possible bashism in /usr/share/automake-1.11/config.guess line 95 (trap with
signal numbers):
trap 'exit 1' 1 2 15
possible bashism in /usr/share/automake-1.7/config.guess line 95 (trap with
signal numbers):
trap 'exit 1' 1 2 15
possible bashism in /usr/share/misc/config.guess line 95 (trap with signal
numbers):
trap 'exit 1' 1 2 15
Cheers,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Re: RFH: bashisms in configure script
On mer., 2010-05-26 at 08:29 +0200, Yves-Alexis Perez wrote:
It is not about whether dash can handle it or not. The bashisms
don't come
from autoconf, the come from what the author's added to
configure.in{,.in}.
I beg to differ, at least some of them don't come from configure.*.
One
example is
http://people.debian.org/~geissert/source-bashisms/evolution_2.30.1.2-2.dsc
where I can't really fine the $3 call (nor any for that matter) in the
configure.* files.
Ok, sorry, didn't see earlier in the thread that it was a false
positive.
Cheers,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Re: RFH: bashisms in configure script
This doesn't necessarily mean that we are drowned by bashisms, as some of those may already be fixed by Debian- provided packages or might affect unused code s/packages/patches/ Don't you think we should run the test *after* the patches got applied? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005261000.58635.mes...@debian.org
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 11:55:58PM +0200, Frans Pop wrote: For example, almost all udebs are listed. Why? Because udebs execute busybox shell as /bin/sh, which happens to be fairly compatible with bash. The busybox /bin/sh is also a dash, but a different version than the dash package. Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526091546.ga14...@wavehammer.waldi.eu.org
Re: RFH: bashisms in configure script
On 26/05/10 08:07, Lucas Nussbaum wrote: On 25/05/10 at 23:10 +0100, Neil Williams wrote: 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) No. 124 is the number of packages that failed to build. Not the number of source packages that silently generated incorrect binary packages. Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfcf029.4040...@debian.org
Re: RFH: bashisms in configure script
On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote: On 26/05/10 08:07, Lucas Nussbaum wrote: On 25/05/10 at 23:10 +0100, Neil Williams wrote: 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) No. 124 is the number of packages that failed to build. Not the number of source packages that silently generated incorrect binary packages. Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Are you volunteering? :-) Just debdiffing doesn't work, since some source packages generate different things by design (think of html converters that generate random identifiers for html and images). Generally, I am interested in the idea of comparing rebuild results to find problems (not only old dash vs new dash, but also current archive vs freshly rebuilt). But I don't have the time to work on that myself. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526111416.ga19...@xanadu.blop.info
Re: RFH: bashisms in configure script
On 26/05/10 13:14, Lucas Nussbaum wrote: On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote: Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Are you volunteering? :-) No. I'm not volunteering on adding LINENO support back to dash either though :-) Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd04a9.2070...@debian.org
Re: RFH: bashisms in configure script
On mercredi 26 mai 2010 02:39:52 Raphael Geissert wrote: [SNIP] Yes, $BASH_SOMETHING is just used to make it easier to see that the following code (probably a bashism) is only executed after checking the shell is actually bash. That and the other FP are the most common ones, yet not that easy to fix (the latter, of course, the former is not a FP.) I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly odd because testing with dash has shown up an actual bashism in xine-lib's configure.ac (which I've just fixed upstream): use of test x == y. Could you please send me by email the files with false negatives? those are very likely bugs in checkbashisms' quotes handling code. Among other false positive there is warning about scripts removed in clean target of debian/rules. Anyway, thanks for the massive run of checkbashism, it made me discover a few bashism in 2 upstream scripts in my packages. Thanks. Cheers, Best regards signature.asc Description: This is a digitally signed message part.
Re: RFH: bashisms in configure script
On Wednesday 26 May 2010 03:00:58 Michael Meskes wrote: Don't you think we should run the test *after* the patches got applied? That's done if the package uses format 3.0 (quilt). Regards, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005261053.40241.geiss...@debian.org
RFH: bashisms in configure script
Hi everyone, dash recently added support for the magic variable $LINENO, which was the last piece to make it POSIX compliant. However, this change made the autoconf- generated configure scripts use dash to execute the script's code. Without support for LINENO, configure scripts exec to bash automatically. With this behaviour change, bashisms in configure scripts are now making packages FTBFS[1]. Due to some bugs in checkbashisms, most of the code in configure scripts was skipped, making those bashisms invisible. An archive-wide check of the source packages gives an estimate of over 3425 source packages with bashisms in *any file*. This doesn't necessarily mean that we are drowned by bashisms, as some of those may already be fixed by Debian- provided packages or might affect unused code (either at the build process or code not included in the final binary package.) A rough estimate of the number of source packages with bashisms in configure scripts (false positives included and not necessarily autoconf's configure script) is 1504. SUMMARY: 1. If your name is on the list at [2] please check at [3] the .dsc file that corresponds to the source packages you co-/maintain, review and fix. The .dsc files contain checkbashisms' output. 2. Do the same for other packages in the list: review, file report[4], and try to provide a patch/NMU. 3. Do the same for other packages in [3] (which are not necessarily in the list below): review, file report[4], try to provide a patch/NMU. Please encourage others to work on these issues. Normally I would process the results and file the bug reports myself but I don't have and won't have time to do it any time soon. I've already tried to find some time yesterday and today to work on checkbashisms to come up with bug fixes[4], and am probably going to find a bit more to only fast-process the results of a new run against the binary packages. Thanks in advance! (before anybody asks/complains, the list of maintainers is too big to be attached to the email, even if compressed.) [1] http://bugs.debian.org/582952 [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt [3] http://people.debian.org/~geissert/source-bashisms/ [4] Please set User: debian-rele...@lists.debian.org and Usertags: goal- dash when filing the report. Severity should be important (or serious if it makes the package FTBFS.) [5] See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497489#13 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497489#40 Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005251613.37139.geiss...@debian.org
Re: RFH: bashisms in configure script
[Raphael Geissert] Hi everyone, dash recently added support for the magic variable $LINENO, which was the last piece to make it POSIX compliant. However, this change made the autoconf- generated configure scripts use dash to execute the script's code. Without support for LINENO, configure scripts exec to bash automatically. What about reverting this change in dash until after Squeeze is released? Now seem like a bad time to make thousand of packages in Debian fail to build from source. :) Or perhaps can this feature be made to turn on or off using some 'set' command, configuration file or command line argument to dash, to allow us to keep the old behaviour for Squeeze while allowing users to convert dash to be POSIX compliant locally? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flpr0jvenf@login2.uio.no
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote: [1] http://bugs.debian.org/582952 [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt That is just a list of all packages per person? It's listing packages that have no shell script in it at all, and also don't have a .dsc file. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100525215130.ga19...@roeckx.be
Re: RFH: bashisms in configure script
dash recently added support for the magic variable $LINENO, which was the last piece to make it POSIX compliant. However, this change made the autoconf- generated configure scripts use dash to execute the script's code. Without support for LINENO, configure scripts exec to bash automatically. Isn't it a bit late in the release cycle for a change with such a major impact? An archive-wide check of the source packages gives an estimate of over 3425 source packages with bashisms in *any file*. This and the file under [2] must contain a *huge* amount of false positives. For example, almost all udebs are listed. Why? Because udebs execute busybox shell as /bin/sh, which happens to be fairly compatible with bash. I think this needs to be trimmed quite a bit before it's useful. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005252356.00453.elen...@planet.nl
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 23:45:56 +0200, Petter Reinholdtsen wrote: What about reverting this change in dash until after Squeeze is released? Now seem like a bad time to make thousand of packages in Debian fail to build from source. :) That's the plan, see #582952. Cheers, Julien signature.asc Description: Digital signature
Re: RFH: bashisms in configure script
On Tue, 25 May 2010 16:13:36 -0500 Raphael Geissert geiss...@debian.org wrote: dash recently added support for the magic variable $LINENO, which was the last piece to make it POSIX compliant. However, this change made the autoconf- generated configure scripts use dash to execute the script's code. Without support for LINENO, configure scripts exec to bash automatically. Can't we just patch this OUT of dash until after the release??? (or forever? or just on buildd's?) All this work for ONE VARIABLE???!?!?! An archive-wide check of the source packages gives an estimate of over 3425 source packages with bashisms in *any file*. This doesn't necessarily mean that we are drowned by bashisms, as some of those may already be fixed by Debian- provided packages or might affect unused code (either at the build process or code not included in the final binary package.) This is just scare mongering - there are packages there which have nothing to do with autoconf or have any configure script of any kind, even the simplest perl script packages! A rough estimate of the number of source packages with bashisms in configure scripts (false positives included and not necessarily autoconf's configure script) is 1504. Which, at a rough estimate, would take at least a year to fix, not including all the transitions that would result. ./configure is a *generated* script too, if dash cannot handle it, dash has to be crippled to let the other packages continue working. Unless autoconf itself has already been patched to fix all of these issues when regenerating ./configure from configure.ac, all this would be a waste of effort anyway. This sounds more like a grave bug in dash by breaking everything else. I can't believe this can happen. It's plain crazy. Please encourage others to work on these issues. Please fix dash instead. Normally I would process the results and file the bug reports myself but I don't have and won't have time to do it any time soon. I've already tried to find some time yesterday and today to work on checkbashisms to come up with bug fixes[4], and am probably going to find a bit more to only fast-process the results of a new run against the binary packages. Thanks in advance! ... for nothing. I'm in no mood to thank anyone for this one. (before anybody asks/complains, the list of maintainers is too big to be attached to the email, even if compressed.) Which is reason enough to fix dash, not thousands of other packages which were fine until this change. One package (one variable) cannot be allowed to break over a THOUSAND source packages. Has someone put the clock back to 1st April? This just has to be a sick joke. Someone please tell me this broken version of dash hasn't been uploaded yet. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpZG2uezv6dR.pgp Description: PGP signature
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 11:51:30PM +0200, Kurt Roeckx wrote: On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote: [1] http://bugs.debian.org/582952 [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt That is just a list of all packages per person? It's listing packages that have no shell script in it at all, and also don't have a .dsc file. They do contain shell scripts, the maintainer script. But they clearly don't generate a warning. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100525220435.ga19...@roeckx.be
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file that
corresponds to the source packages you co-/maintain, review and fix. The
.dsc
files contain checkbashisms' output.
I get alot of them that have:
possible bashism in ./configure line 22 ($BASH_SOMETHING):
elif test -n ${BASH_VERSION+set} (set -o posix) /dev/null 21; then
possible bashism in ./configure line 147 ($BASH_SOMETHING):
$as_unset BASH_ENV || test ${BASH_ENV+set} != set || {
BASH_ENV=; export BASH_ENV; }
This is autogenerated code by autoconf (2.59). I think that code
that makes sure it behaves the way you want under bash isn't
really going to be a problem if you run it with something else.
Kurt
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100525220732.ga19...@roeckx.be
Re: RFH: bashisms in configure script
On 25/05/10 23:45, Petter Reinholdtsen wrote: What about reverting this change in dash until after Squeeze is released? Now seem like a bad time to make thousand of packages in Debian fail to build from source. :) See bug #582952. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfc465d.1080...@debian.org
Re: RFH: bashisms in configure script
On Tue, 25 May 2010 16:13:36 -0500 Raphael Geissert geiss...@debian.org wrote: A much more sane list is in the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) Please, let's get some accurate figures before raising things like this. (Oh, and yes, putting a patched dash into unstable and putting this broken one into experimental is a VERY good idea IMHO. It's kinda why we have experimental in the first place. Sheesh! This thing gonna give me nightmares.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpexJad0mjTS.pgp Description: PGP signature
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 11:10:10PM +0100, Neil Williams wrote: On Tue, 25 May 2010 16:13:36 -0500 Raphael Geissert geiss...@debian.org wrote: A much more sane list is in the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) Please, let's get some accurate figures before raising things like this. (Oh, and yes, putting a patched dash into unstable and putting this broken one into experimental is a VERY good idea IMHO. It's kinda why we have experimental in the first place. Sheesh! This thing gonna give me nightmares.) You're getting things the wrong way around. The version of dash that will be put in experimental will be the correct one, the one in unstable will be the crippled one. The reason things fails isn't because of dash, but because of sloppy programming on behalf of people that still believe that bash is the say all and end all when it comes to shell scripts. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100525221823.gk24...@test5.acc.umu.se
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote: 1. If your name is on the list at [2] please check at [3] the .dsc file that corresponds to the source packages you co-/maintain, review and fix. The .dsc files contain checkbashisms' output. Is there some kind of documentation on what those errors really mean? Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100525222056.ga20...@roeckx.be
Re: RFH: bashisms in configure script
I demand that Kurt Roeckx may or may not have written...
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file
that corresponds to the source packages you co-/maintain, review and fix.
The .dsc files contain checkbashisms' output.
I get alot of them that have:
possible bashism in ./configure line 22 ($BASH_SOMETHING):
elif test -n ${BASH_VERSION+set} (set -o posix) /dev/null 21; then
possible bashism in ./configure line 147 ($BASH_SOMETHING):
$as_unset BASH_ENV || test ${BASH_ENV+set} != set || {
BASH_ENV=; export BASH_ENV; }
This is autogenerated code by autoconf (2.59). I think that code that
makes sure it behaves the way you want under bash isn't really going to be
a problem if you run it with something else.
I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly odd
because testing with dash has shown up an actual bashism in xine-lib's
configure.ac (which I've just fixed upstream): use of test x == y.
--
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
This tagline was stolen by the International Brotherhood of Tagline Thieves.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512296bb08%li...@youmustbejoking.demon.co.uk
Re: RFH: bashisms in configure script
This one time, at band camp, Kurt Roeckx said: On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote: 1. If your name is on the list at [2] please check at [3] the .dsc file that corresponds to the source packages you co-/maintain, review and fix. The .dsc files contain checkbashisms' output. Is there some kind of documentation on what those errors really mean? They largely mean that checkbashisms is an overly blunt tool for the job at hand. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFH: bashisms in configure script
On 25/05/10 23:13, Raphael Geissert wrote: Normally I would process the results and file the bug reports myself but I don't have and won't have time to do it any time soon. I've already tried to find some time yesterday and today to work on checkbashisms to come up with bug fixes[4], and am probably going to find a bit more to only fast-process the results of a new run against the binary packages. It would also be good to build all the archive (or all the affected packages) with and without LINENO support in dash, and then debdiff'ing them and check if they are equal or not. And I've seen configure scripts with the following bashism that checkbashisms didn't find: if test x$foo == xyes; then (== is a bashism, should be =). Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfc50b3.40...@debian.org
Re: RFH: bashisms in configure script
[Kurt Roeckx]
I get alot of them that have:
possible bashism in ./configure line 22 ($BASH_SOMETHING):
elif test -n ${BASH_VERSION+set} (set -o posix) /dev/null 21; then
possible bashism in ./configure line 147 ($BASH_SOMETHING):
$as_unset BASH_ENV || test ${BASH_ENV+set} != set || {
BASH_ENV=; export BASH_ENV; }
And more false positives:
possible bashism in ./configure line 44 ($BASH_SOMETHING):
if test -z $BASH_VERSION$ZSH_VERSION \
(test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
possible bashism in ./configure line 367 (should be word 21):
$as_echo $as_me:${as_lineno-$LINENO}: error: $1 $3
Both were produced by autoconf 2.65.
First is a false positive for the same reason Kurt's example is.
Second is a false positive because $3 in this instance is a numbered
file descriptor.
Peter
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100525230926.gc18...@p12n.org
Re: RFH: bashisms in configure script
Kurt Roeckx wrote: On Tue, May 25, 2010 at 11:51:30PM +0200, Kurt Roeckx wrote: On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote: [1] http://bugs.debian.org/582952 [2] http://people.debian.org/~geissert/source-bashisms/dd-list.txt That is just a list of all packages per person? It's listing packages that have no shell script in it at all, and also don't have a .dsc file. They do contain shell scripts, the maintainer script. But they clearly don't generate a warning. I accidentally screwed the call to dd-list(1) and I made it list all the maintainers of every package in the archive. I've fixed it already some hours ago. The .dsc files are at: http://people.debian.org/~geissert/source-bashisms/ (there's a sub-directory called 'empty' that has all the, empty, .dsc files.) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hthpu6$vt...@dough.gmane.org
Re: RFH: bashisms in configure script
Neil Williams wrote:
On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert geiss...@debian.org wrote:
dash recently added support for the magic variable $LINENO, which was the
last piece to make it POSIX compliant. However, this change made the
autoconf- generated configure scripts use dash to execute the script's
code. Without support for LINENO, configure scripts exec to bash
automatically.
Can't we just patch this OUT of dash until after the release??? (or
forever? or just on buildd's?)
The plan for now is to disable support for LINENO, as mentioned in the br.
All this work for ONE VARIABLE???!?!?!
POSIX compliance too.
An archive-wide check of the source packages gives an estimate of over
3425 source packages with bashisms in *any file*. This doesn't
necessarily mean that we are drowned by bashisms, as some of those may
already be fixed by Debian- provided packages or might affect unused code
(either at the build process or code not included in the final binary
package.)
This is just scare mongering - there are packages there which have
nothing to do with autoconf or have any configure script of any kind,
even the simplest perl script packages!
The dd-list was bogus and I fixed it already. The .dsc files in the
directory did not change, however.
./configure is a *generated* script too, if dash cannot handle it, dash
has to be crippled to let the other packages continue working. Unless
autoconf itself has already been patched to fix all of these issues when
regenerating ./configure from configure.ac, all this would be a waste
of effort anyway.
It is not about whether dash can handle it or not. The bashisms don't come
from autoconf, the come from what the author's added to configure.in{,.in}.
Someone please tell me this broken version of dash hasn't been uploaded
yet.
dash isn't broken. It is in testing already.
Regards,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthqbf$1n...@dough.gmane.org
Re: RFH: bashisms in configure script
Darren Salt wrote:
I demand that Kurt Roeckx may or may not have written...
On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote:
1. If your name is on the list at [2] please check at [3] the .dsc file
that corresponds to the source packages you co-/maintain, review and
fix. The .dsc files contain checkbashisms' output.
I get alot of them that have:
possible bashism in ./configure line 22 ($BASH_SOMETHING):
elif test -n ${BASH_VERSION+set} (set -o posix) /dev/null 21;
then possible bashism in ./configure line 147 ($BASH_SOMETHING):
$as_unset BASH_ENV || test ${BASH_ENV+set} != set || {
BASH_ENV=; export BASH_ENV; }
Yes, $BASH_SOMETHING is just used to make it easier to see that the
following code (probably a bashism) is only executed after checking the
shell is actually bash. That and the other FP are the most common ones, yet
not that easy to fix (the latter, of course, the former is not a FP.)
I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly
odd because testing with dash has shown up an actual bashism in xine-lib's
configure.ac (which I've just fixed upstream): use of test x == y.
Could you please send me by email the files with false negatives? those are
very likely bugs in checkbashisms' quotes handling code.
Thanks.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthqk6$1n...@dough.gmane.org
Re: RFH: bashisms in configure script
Kurt Roeckx wrote: On Tue, May 25, 2010 at 04:13:36PM -0500, Raphael Geissert wrote: 1. If your name is on the list at [2] please check at [3] the .dsc file that corresponds to the source packages you co-/maintain, review and fix. The .dsc files contain checkbashisms' output. Is there some kind of documentation on what those errors really mean? Yes, most are documented at the following page. I'm going to add more info about recently-added and some undocumented checks in a moment. https://wiki.ubuntu.com/DashAsBinSh Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hthqtn$1n...@dough.gmane.org
Re: RFH: bashisms in configure script
Emilio Pozuelo Monfort wrote: It would also be good to build all the archive (or all the affected packages) with and without LINENO support in dash, and then debdiff'ing them and check if they are equal or not. A full archive rebuild was already done by Lucas (see the br against dash for details.) One with a version of dash without support for LINENO is useless, as that's what it used to be. And I've seen configure scripts with the following bashism that checkbashisms didn't find: if test x$foo == xyes; then (== is a bashism, should be =). Please send me those configure scripts by email (preferably adding a comment at the end of the same line that says BASHISM, so that I can just inject it into my testsuite.) Thanks. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hthqr9$1n...@dough.gmane.org
Re: RFH: bashisms in configure script
Hi,
Given the recent responses I'm providing some more info, updates, and hints.
Raphael Geissert wrote:
This doesn't necessarily mean that we are drowned by bashisms, as some of
those may already be fixed by Debian- provided packages or might affect
unused code
s/packages/patches/
(before anybody asks/complains, the list of maintainers is too big to be
attached to the email, even if compressed.)
If you were one of those who checked the dd-list.txt file right after I sent
my original email and up to two hours later, please re-check it. It was
bogus.
dd-list.txt *only* contains the list of maintainers/packages with bashisms
in a 'configure' script. A new list for maintainers/packages with any kind
of bashism (or false positive) in any file can now be found at:
Information about bashisms (how to fix them) and how to understand
checkbashisms' output can be found at:
https://wiki.ubuntu.com/DashAsBinSh
* Common false positive:
---
possible bashism in ./configure line nnn (should be word 21):
$as_echo $as_me:${as_lineno-$LINENO}: error: $1 $3
---
This one is safe. It is generated by autoconf and $3 points to a numeric
file descriptor.
---
some sort of detection in *.diff or *.dpatch files
---
In this case those files use a shell wrapper that executes another program
to process the file. checkbashisms attempts to detect them, but it fails in
some cases.
---
unsafe echo with backslash:
---
If the output of echo is piped to grep, verified with test/[ or case; in
most cases it is just some shell code that is used to determine whether the
echo command expands backlashes by default.
* Not false positives, just indicators[1], but common too:
$BASH
RANDOM=
(OS|MACH)TYPE=
HOST(TYPE|NAME)=
BASH(_SOMETHING)=
[1] they help identify shell tests.
Yes, I'm aware of the high number of false positives and indicators noise.
There are some false negatives too.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hthsoh$7u...@dough.gmane.org
