ee all the configure scripts that
*don't* have bashisms in them run at dash's speed on Debian, and the fallback
code for when $LINENO isn't available at all is a monstrosity that I would like
to scrap.
zw
Quoting Richard Laager (2021-11-10 20:16:31)
> Can we just enable LINENO in dash then, let the other packages FTBFS, and
> people who care about the packages that FTBFS can either:
in the best case, a package will FTBFS but it can also happen that the
configure script will just do something differ
"Andrej Shadura" writes:
> Well, we might make bash non-essential at one point. OTOH development
> systems are likely to have it anyway.
A compromise could be to make it build-essential instead.
- ilmari
On 11/10/21 12:50 PM, Andrej Shadura wrote:
On Wed, 10 Nov 2021, at 19:18, Sam Hartman wrote:
I understand that it's generally better to fix bashisms in configure
scripts.
Is it possible to force autoconf to prefer bash for a given configure
script if it's difficult or undesira
>>>>> "Andrej" == Andrej Shadura writes:
Andrej> Hi all, Yesterday I uploaded dash with LINENO feature
Andrej> switched on again, which has the side effect of exposing
Andrej> bashisms in configure scripts. Previously, they were
Andrej> obscur
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
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 sta
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 b
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
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 de
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
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
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
> >>
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.
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.
Bastia
> > 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 app
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
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
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 kerne
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 (sh
On 25/05/10 at 23:10 +0100, Neil Williams wrote:
> On Tue, 25 May 2010 16:13:36 -0500
> Raphael Geissert 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
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? Woul
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
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 de
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.
>
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
able 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
>> neces
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
>&g
[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 2>&1; then
> possible bashism in ./configure line 147 ($BASH_SOMETHING):
> $as_unset BASH_ENV || test "${BASH_EN
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],
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
> >
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 con
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 doc
On Tue, May 25, 2010 at 11:10:10PM +0100, Neil Williams wrote:
> On Tue, 25 May 2010 16:13:36 -0500
> Raphael Geissert 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
On Tue, 25 May 2010 16:13:36 -0500
Raphael Geissert 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-
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...@
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
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 packa
n 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
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
signa
ipts 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* a
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
[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, configu
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
On Thu, Apr 16 2009, Josselin Mouette wrote:
> Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
>> So, no, policy does not just document current practice. Policy
>> tries to document what is right.
>
> I think it should be both. When we do things right, they should be
>
Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
> So, no, policy does not just document current practice. Policy
> tries to document what is right.
I think it should be both. When we do things right, they should be
specified in the Policy, and there’s no point specifyi
Le mercredi 15 avril 2009 à 17:12 -0500, Raphael Geissert a écrit :
> Then there must be some sort of missunderstanding. My intention was not to
> troll, but to demonstrate the implications of what you said. I would like
> to apologise for my previous message as I had understood something
> complet
On Wed, Apr 15 2009, Josselin Mouette wrote:
> Policy documents practice.
I wish people would not say that. It is not true; and hasn't
been. And, moreover, we would not _want_ that to be true; there should
be no excuse to justify wanting to enshrine broken or bad practices
into policy.
Josselin Mouette wrote:
> Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit :
[...]
>
>> And taking your statement to the extreme, it means that if zsh was used
>> as /bin/sh then no other shell interpreter could ever be used as /bin/sh
>> ever again but a fork of zsh.
>
> I’m pr
Josselin Mouette writes:
> Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
>> The advantage of the current Policy approach is that we have some hope
>> of introducing a new /bin/sh down the road, and we don't require that
>> packages comply with bugs in dash that should be fixed i
Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit :
> > Policy documents practice. When that new /bin/sh exists, you can change
>
> bash is the current /bin/sh, from your statements I could imply that we
> should require all /bin/sh's to support: b0rken bash arrrays, shell
> regexe
Josselin Mouette wrote:
> Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
>> > Actually it would be better to specify that scripts must work with both
>> > sh implementations available in Debian, being bash and dash, rather
>> > than making nothing more than a fork of the POSIX spe
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
> > Actually it would be better to specify that scripts must work with both
> > sh implementations available in Debian, being bash and dash, rather than
> > making nothing more than a fork of the POSIX spec.
>
> The advantage of the c
Josselin Mouette writes:
> It is not the role of the policy to specify the exact requirements of
> the /bin/sh implementation.
It is, however, the role of Policy to specify the minimum required feature
set that all scripts can assume.
> Actually it would be better to specify that scripts must w
Le mardi 14 avril 2009 à 18:45 -0500, Raphael Geissert a écrit :
> what feature provided by dash is being deprecated?
> Like Russ said, if there's any feature not covered by policy that is
> reasonable to be required please say so.
It is not the role of the policy to specify the exact requirements
On Apr 15, Raphael Geissert wrote:
> what feature provided by dash is being deprecated?
You are the one who started the thread. Please come back when you will
actually know what you are proposing exactly.
> Like Russ said, if there's any feature not covered by policy that is
> reasonable to be r
Marco d'Itri wrote:
[...]
> The point is not to eliminate bashism but dashism, and so far there are
> no demonstrated benefits to deprecating features available in dash but
> not in posh.
>
what feature provided by dash is being deprecated?
Like Russ said, if there's any feature not covered by pol
On Apr 14, Stefano Zacchiroli wrote:
> Beside "local" per se, what is exactly the problem? If you badly need
> bash-specific features you can use /bin/bash as the interpreter.
Every deviation from upstream has a cost, which needs to be justified
by a cost-benefits analisys.
The point is not to el
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
> > * Bashisms-free archive
> This is useless. You are basically proposing to remove every usage of
> "local" and a few other directives for no good reason but at a huge cost.
Beside "local" per se
Marco d'Itri wrote:
> On Apr 12, Raphael Geissert wrote:
>
>> I don't have a list at hand (I do have a sort of list in another machine
>> which is unreachable atm); but the first one that comes to my mind is the
>> use of 'type', it's output is unreliable and in some shell interpreters
>> it is
On Apr 12, Raphael Geissert wrote:
> I don't have a list at hand (I do have a sort of list in another machine
> which is unreachable atm); but the first one that comes to my mind is the
> use of 'type', it's output is unreliable and in some shell interpreters it
> is not implemented. Another one
Marco d'Itri wrote:
> On Apr 12, "Roberto C. Sánchez" wrote:
>
>> Policy specifically states that use of "local" is permitted [0]:
> So exactly what do you want to disallow which is supported by dash but
> not by policy, and for which purpose?
>
I don't have a list at hand (I do have a sort of
On Apr 12, "Roberto C. Sánchez" wrote:
> Policy specifically states that use of "local" is permitted [0]:
So exactly what do you want to disallow which is supported by dash but
not by policy, and for which purpose?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
>
> > * Bashisms-free archive
> This is useless. You are basically proposing to remove every usage of
> "local" and a few other directives for no good reason but at a huge cost.
>
Policy specifica
m...@linux.it (Marco d'Itri) writes:
> On Apr 12, Raphael Geissert wrote:
>> * Bashisms-free archive
> This is useless. You are basically proposing to remove every usage of
> "local" and a few other directives for no good reason but at a huge
> cost.
No, he&#x
On Apr 12, Raphael Geissert wrote:
> * Dash as default /bin/sh
This is good.
> * Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
"local" and a few other directives for no good reason but at a huge cost.
> needed to support d
Hello everyone,
I would like to propose the following Release Goals for squeeze:
* Dash as default /bin/sh
A lot of work was done on this RG already for lenny but, sadly, it didn't make
it. Further improvements to checkbashisms as well as support for checking for
bashisms in all /bin/s
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 hop
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 ./u
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 ./u
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 documentin
* 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
[ 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
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
>
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 reaso
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
>&
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 tha
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 exten
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 e
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
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 the
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
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 $
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):
>
> 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
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]> <ht
[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 "
s 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, em
[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, ema
Raphael Geissert wrote:
> Kevin B. McCarty <[EMAIL PROTECTED]>
>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
"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'l
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
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 th
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
hlist 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 int
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",
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 ala
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 foo
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
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
1 - 100 of 124 matches
Mail list logo
