Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote: Roberto C. Sanchez [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert [EMAIL PROTECTED] writes: Russ Allbery wrote: Clint Adams [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: List of packages shipping shell scripts with bashisms + MBF proposal
[ Please Cc: me, I don't read the list ] * 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: List of packages shipping shell scripts with bashisms + MBF proposal
* Ben Pfaff wrote: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Am Sonntag 10 Februar 2008 schrieb Ralf Wildenhues: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, 2008-02-09 at 16:39 -0800, Russ Allbery wrote: Raphael Geissert [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, 2008-02-09 at 16:59 -0800, Ben Pfaff wrote: Raphael Geissert [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] libtool Libtool is a false positive. The script /usr/bin/libtool contains some C program text embedded in a here document. Detection of that kind of stuff is already in latest checkbashisms and, hopefully, those false positives are gone. Atm, checkbashisms only complains with this: _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb possible bashism in ./usr/bin/libtool line 1218 (trap with signal numbers): trap $run $rm $removelist; exit $EXIT_FAILURE 1 2 15 possible bashism in ./usr/bin/libtool line 1237 (trap with signal numbers): trap $run $rm $removelist; exit $EXIT_FAILURE 1 2 15 possible bashism in ./usr/bin/libtool line 5323 (trap with signal numbers): trap $rm $cwrappersource $cwrapper; exit $EXIT_FAILURE 1 2 15 possible bashism in ./usr/bin/libtool line 5676 (trap with signal numbers): trap $rm $output; exit $EXIT_FAILURE 1 2 15 I should further note that the Libtool version in experimental makes use of some bashisms as optimization. These are put in place iff, at the time the Libtool package is configured, the chosen shell is deemed capable enough. This setup can break /usr/bin/libtool, for example, if /bin/sh is later switched from bash to dash. Why not just check if the shell is bash at run time? I've seen some scripts testing for $BASH which works as expected: $ bash 'echo $BASH' /bin/bash $ dash 'echo $BASH' Cheers, Ralf Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Russ Allbery [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Ben Pfaff [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
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. When the names are used, this confusion is avoided. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Clint Adams [EMAIL PROTECTED] writes: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Clint Adams [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Ben Pfaff wrote: Raphael Geissert [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Russ Allbery wrote: Clint Adams [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Kurt Roeckx [EMAIL PROTECTED] libtool Libtool is a false positive. The script /usr/bin/libtool contains some C program text embedded in a here document. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
[Raphael Geissert] Debian sysvinit maintainers [EMAIL PROTECTED] sysv-rc 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
[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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Jan 30, 2008 11:31 AM, Cyril Brulebois [EMAIL PROTECTED] 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? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote: Stefano Zacchiroli [EMAIL PROTECTED] 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? [EMAIL PROTECTED],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 signature.asc Description: Digital signature
Specifying where to follow-up (was: List of packages shipping shell scripts with bashisms + MBF proposal)
Steffen Grunewald [EMAIL PROTECTED] writes: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote: Hamish Moffatt [EMAIL PROTECTED] ax25-tools (U) hf (U) 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 [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
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? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On mar, 2008-01-29 at 19:58 -0600, Raphael Geissert wrote: Rene Mayorga [EMAIL PROTECTED] afbackup afbackup-client False positive Both one have csh scripts. Cheers -- Rene Mauricio Mayorga signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Specifying where to follow-up (was: List of packages shipping shell scripts with bashisms + MBF proposal)
Ben Finney wrote: Steffen Grunewald [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
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? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
checkbashisms: fails to detect shell wrappers (was: Re: List of packages shipping shell scripts with bashisms + MBF proposal)
Package: devscripts Version: 2.10.13 User: [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Stefano Zacchiroli [EMAIL PROTECTED] writes: 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert [EMAIL PROTECTED] writes: 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Raphael Geissert [EMAIL PROTECTED] writes: 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Thanks Russ for your input. Russ Allbery wrote: Raphael Geissert [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Wed, 2008-01-30 at 10:29 -0800, Russ Allbery wrote: Raphael Geissert [EMAIL PROTECTED] 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Adam D. Barratt [EMAIL PROTECTED] writes: 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
List of packages shipping shell scripts with bashisms + MBF proposal
-BEGIN PGP SIGNED MESSAGE- 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) [EMAIL PROTECTED] docbook2x (U) Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] wavesurfer Gregory Colpart (evolix) [EMAIL PROTECTED] pppoeconf Stefan Hornburg (Racke) [EMAIL PROTECTED] courier-pop courier-pop-ssl sqwebmail Eric Schwartz (Skif) [EMAIL PROTECTED] libyaz2-dev Stefan Alfredsson [EMAIL PROTECTED] monit Thomas Anders [EMAIL PROTECTED] libsnmp-base (U) Micah Anderson [EMAIL PROTECTED] rkhunter Hakan Ardo [EMAIL PROTECTED] gcc-avr Ben Armstrong [EMAIL PROTECTED] tuxpaint Richard Atterer [EMAIL PROTECTED] jigdo-file Khalid Aziz [EMAIL PROTECTED] kexec-tools Mathieu Baeumler [EMAIL PROTECTED] blackbox (U) Paul Bame [EMAIL PROTECTED] pmccabe Denis Barbier [EMAIL PROTECTED] kbd (U) Andreas Barth [EMAIL PROTECTED] netpbm pppoe Mirco Bauer [EMAIL PROTECTED] beagle (U) mono-1.0-devel (U) Daniel Baumann [EMAIL PROTECTED] expect-dev gnulib gnunet-client (U) live-initramfs (U) virtualbox-ose (U) wmii Ian Beckwith [EMAIL PROTECTED] surfraw (U) Luca Bedogni [EMAIL PROTECTED] foo2zjs (U) Hilko Bengen [EMAIL PROTECTED] virtualbox-ose (U) Felix Berger [EMAIL PROTECTED] phpix (U) Marco Bertorello [EMAIL PROTECTED] powernowd Marcus Better [EMAIL PROTECTED] tomcat5.5 (U) Sylvain Beucler [EMAIL PROTECTED] page-crunch Rene van Bevern [EMAIL PROTECTED] cl-launch (U) Darren Blaber [EMAIL PROTECTED] atheme-services (U) Julien BLACHE [EMAIL PROTECTED] openser (U) Eduard Bloch [EMAIL PROTECTED] encfs mono-1.0-devel (U) Achim Bohnet [EMAIL PROTECTED] kdebluetooth (U) W. Borgert [EMAIL PROTECTED] docbook2x (U) Dmitry Borodaenko [EMAIL PROTECTED] samizdat Fathi Boudra [EMAIL PROTECTED] kdebluetooth (U) Fathi Boudra [EMAIL PROTECTED] kdesdk-scripts (U) Nicholas Breen [EMAIL PROTECTED] jigl Adrian Bridgett [EMAIL PROTECTED] xmcd Thomas Bushnell, BSG [EMAIL PROTECTED] gnucash jacal slib Bruno Barrera C. [EMAIL PROTECTED] blackbox Paul Cager [EMAIL PROTECTED] maven2 (U) Hubert Chan [EMAIL PROTECTED] noweb Hubert Chathi [EMAIL PROTECTED] gnustep-common (U) gnustep-make-ogo (U) Pierre Chifflier [EMAIL PROTECTED] nufw Volker Christian [EMAIL PROTECTED] synce-serial Dennis L. Clark [EMAIL PROTECTED] bnetd Isaac Clerencia [EMAIL PROTECTED] kexi (U) David Cobac [EMAIL PROTECTED] page-crunch (U) David Coe [EMAIL PROTECTED] ispell Console utilities maintainers [EMAIL PROTECTED] kbd Julien Cristau [EMAIL PROTECTED] ocaml-mode (U) Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] sawfish Maximiliano Curia [EMAIL PROTECTED] tkman Tim Cutts [EMAIL PROTECTED] tkcvs Julien Danjou [EMAIL PROTECTED] rebuildd Debian allegro packages maintainers [EMAIL PROTECTED] allegro-examples libalogg-dev Debian ALSA Maintainers [EMAIL PROTECTED] ld10k1 Debian CLI Applications Team [EMAIL PROTECTED] beagle Debian Cryptsetup Team [EMAIL PROTECTED] cryptsetup Debian Cyrus SASL Team [EMAIL PROTECTED] sasl2-bin Debian Foo2zjs Maintainers [EMAIL PROTECTED] foo2zjs Debian GCC Maintainers [EMAIL PROTECTED] gcc-3.3 gcc-3.4 gcc-4.1 Debian GIS Project [EMAIL PROTECTED] gpsdrive-scripts Debian GNOME Maintainers [EMAIL PROTECTED] gtranslator (U) Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-common gnustep-make-ogo Debian Hamradio Maintainers [EMAIL PROTECTED] ax25-tools hf Debian Hebrew Packaging Team [EMAIL PROTECTED] user-he Debian IRC Team [EMAIL PROTECTED] atheme-services Debian Java Maintainers [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Jan 30, 2008 10:58 AM, Raphael Geissert [EMAIL PROTECTED] wrote: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Cyril Brulebois 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 And as for debian/rules Lucas Nussbaum rebuilt the archive with dash as /bin/sh :) Cheers, Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
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 Cheers, -- Cyril Brulebois pgpu6gpae1W7J.pgp Description: PGP signature
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Paul Wise wrote: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
