bashism question

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bashism question

Michael Meskes
With our move to dash as sh we have to remove all bashisms from scripts
run by /bin/sh. However, checkbashism seems to moan about clauses that
work in dash as well. I don't know in which shells a trap with a signal number
is guaranteed to work, but it seems to work well in dash.

I just ran a short test, so if the devil's in the detail I might have
missed something, but nevertheless I wonder if this feature can safely
be used.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [hidden email]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
Michael Meskes wrote, 2008-06-23, 10:07:27 +0200:
> With our move to dash as sh we have to remove all bashisms from
> scripts  run by /bin/sh. However, checkbashism seems to moan
> about clauses that work in dash as well.
> I don't know in which shells a trap with a signal number is
> guaranteed to work, but it seems to work well in
> dash.

It's not guaranteed to work in any shell implementing POSIX without
extensions, which is what Policy says you're allowed to rely on (well, plus
a few extensions, but not including trap and kill with signal numbers).

In general the definition of bashism used by checkbashisms and lintian in
this case is "not portable to a shell implementing SUSv3 2004 without
extensions", with the potential exception of those explicitly allowed by
Policy.

> I just ran a short test, so if the devil's in the detail I might have
> missed something, but nevertheless I wonder if this feature can safely
> be used.

It's safe for use with dash, but using it is technically a violation of
Policy (albeit a widespread one). There is a Policy bug open requesting that
the XSI extensions for trap and kill be permitted (#477240).

Regards,

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

James McCoy
In reply to this post by Michael Meskes
On Mon, Jun 23, 2008 at 10:07:27AM +0200, Michael Meskes wrote:
> With our move to dash as sh we have to remove all bashisms from scripts
> run by /bin/sh. However, checkbashism seems to moan about clauses that
> work in dash as well. I don't know in which shells a trap with a signal number
> is guaranteed to work, but it seems to work well in dash.

Policy currently doesn't allow use of XSI extensions which is what
"trap -SIGNAL_NAME" is.  Therefore, checkbashisms is flagging such use
until policy is clarified about this behavior[0].

[0] - http://bugs.debian.org/477240
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Michael Meskes
In reply to this post by Adam D. Barratt
On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote:
> It's not guaranteed to work in any shell implementing POSIX without  
> extensions, which is what Policy says you're allowed to rely on (well,
> plus a few extensions, but not including trap and kill with signal
> numbers).

Right. But what does this mean in terms of our Lenny release goal "dash as
sh" which essantially was what I meant to ask.

> It's safe for use with dash, but using it is technically a violation of  
> Policy (albeit a widespread one). There is a Policy bug open requesting
> that the XSI extensions for trap and kill be permitted (#477240).

>From this I'd say for Lenny using trap with a signal number is fine.

Also they same question comes up with the "local" keyword. Dash seems to
support this, while it is not POSIX.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [hidden email]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

James McCoy
On Mon, Jun 23, 2008 at 07:28:36PM +0200, Michael Meskes wrote:
> On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote:
> > It's safe for use with dash, but using it is technically a violation of  
> > Policy (albeit a widespread one). There is a Policy bug open requesting
> > that the XSI extensions for trap and kill be permitted (#477240).
>
> >From this I'd say for Lenny using trap with a signal number is fine.
>
> Also they same question comes up with the "local" keyword. Dash seems to
> support this, while it is not POSIX.

The "local" keyword is an explicitly supported extension.  These are
discussed in Section 10.4 of policy.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
In reply to this post by Michael Meskes
On Mon, 2008-06-23 at 19:28 +0200, Michael Meskes wrote:
> On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote:
> > It's not guaranteed to work in any shell implementing POSIX without  
> > extensions, which is what Policy says you're allowed to rely on (well,
> > plus a few extensions, but not including trap and kill with signal
> > numbers).
>
> Right. But what does this mean in terms of our Lenny release goal "dash as
> sh" which essantially was what I meant to ask.

I'd assume it doesn't make any difference in terms of that release goal
as (as you noted) dash supports the syntax.

> > It's safe for use with dash, but using it is technically a violation of  
> > Policy (albeit a widespread one). There is a Policy bug open requesting
> > that the XSI extensions for trap and kill be permitted (#477240).
>
>From this I'd say for Lenny using trap with a signal number is fine.

As fine as it was for etch :-)

> Also they same question comes up with the "local" keyword. Dash seems to
> support this, while it is not POSIX.

Policy contains an explicit exemption for "local", although it places
several restrictions on exactly how the keyword may be used. Again, if
dash supports the syntax then the "dash as sh" release goal is
achievable without changing the code; whether that code is Policy
compliant is another matter.

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Michael Meskes
In reply to this post by James McCoy
On Mon, Jun 23, 2008 at 01:33:21PM -0400, James Vega wrote:
> > >From this I'd say for Lenny using trap with a signal number is fine.
> >
> > Also they same question comes up with the "local" keyword. Dash seems to
> > support this, while it is not POSIX.
>
> The "local" keyword is an explicitly supported extension.  These are
> discussed in Section 10.4 of policy.

Thanks to James and Adam for the explanations. Maybe I could ping the
devscripts maintainers to add a not-xsi-but-supported-by-policy flag.
:-)

Michael

--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [hidden email]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
On Mon, 2008-06-23 at 19:45 +0200, Michael Meskes wrote:

> On Mon, Jun 23, 2008 at 01:33:21PM -0400, James Vega wrote:
> > > >From this I'd say for Lenny using trap with a signal number is fine.
> > >
> > > Also they same question comes up with the "local" keyword. Dash seems to
> > > support this, while it is not POSIX.
> >
> > The "local" keyword is an explicitly supported extension.  These are
> > discussed in Section 10.4 of policy.
>
> Thanks to James and Adam for the explanations. Maybe I could ping the
> devscripts maintainers to add a not-xsi-but-supported-by-policy flag.
> :-)

/me coughs in the direction of devscripts' Uploaders field (I'm assuming
you'd noticed, but just in case :-)

Assuming "not-POSIX-but-supported-by-policy" checkbashisms already has a
flag to indicate whether "echo -n" should be flagged for exactly this
reason; otherwise it errs on the side of not flagging constructs that
are policy-compliant.

Supporting "local x" would be relatively simple; suggestions for a
reliable regex to catch use of -a/-o welcome... :)

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Bernd Eckenfels
In reply to this post by Michael Meskes
In article <[hidden email]> you wrote:
> work in dash as well. I don't know in which shells a trap with a signal number
> is guaranteed to work, but it seems to work well in dash.

The signal numbers are different on various architectures. I think in the
GNU world at least mach and FreeBSD kernels have different ones. So it is
less a question of shell syntax but portability.

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Brian M. Carlson
In reply to this post by Michael Meskes
On Mon, Jun 23, 2008 at 10:07:27AM +0200, Michael Meskes wrote:
>With our move to dash as sh we have to remove all bashisms from scripts
>run by /bin/sh. However, checkbashism seems to moan about clauses that
>work in dash as well. I don't know in which shells a trap with a signal number
>is guaranteed to work, but it seems to work well in dash.

As far as I'm aware, there are three shells in Debian that can be used
as /bin/sh: bash, dash, and posh[0].  bash is, in general, the most
featureful of these.  Just because something works in one does not mean
that it works in all of them.  Notably, posh implements the most minimal
set of features, and last time I checked, my system failed to boot
because scripts were using features not mandated by policy.

So, if you're going to fix bugs due to bashisms, please fix them all.
They are all policy violations, and there's no reason to fix only some
bugs.

As for the signal numbers, different architectures have different signal
numbers.  See signal(7), but the most common ones *are* identical.
However, signals such as SIGUSR1 and SIGUSR2 are not, and using a number
for these will break on at least alpha, mips, mipsel, and sparc[1].  Using
names is not only more portable, it is more explicit.  Everyone knows
what SIGABRT does, but not everyone knows what signal 4 does.  Think of
using signal numbers as using magic numbers: it's a bad programming
practice.

Also, as GNU/kFreeBSD becomes more usable, it will be important to have
shell scripts work across kernels.  The FreeBSD kernel does not match
any Linux architecture in its assignment of signal numbers, so fixing
these now is a good idea.

[0] It would be nice if zsh were added to this list, but I'm not holding
my breath.
[1] Assuming, of course, that most people use i386 or amd64 as their
main platform, and program accordingly.  Judging by the number of FTBFS
bugs on sparc due to alignment problems, this is a safe assumption.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

signature.asc (852 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Russ Allbery-2
In reply to this post by Adam D. Barratt
"Adam D. Barratt" <[hidden email]> writes:

> Supporting "local x" would be relatively simple; suggestions for a
> reliable regex to catch use of -a/-o welcome... :)

There was a fairly good one in Lintian that I took out once Policy blessed
it, or at least we didn't get a lot of false positive reports.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Russ Allbery-2
In reply to this post by Brian M. Carlson
"brian m. carlson" <[hidden email]> writes:

> As for the signal numbers, different architectures have different signal
> numbers.  See signal(7), but the most common ones *are* identical.
> However, signals such as SIGUSR1 and SIGUSR2 are not, and using a number
> for these will break on at least alpha, mips, mipsel, and sparc[1].
> Using names is not only more portable, it is more explicit.  Everyone
> knows what SIGABRT does, but not everyone knows what signal 4 does.
> Think of using signal numbers as using magic numbers: it's a bad
> programming practice.

I'm personally leaning towards modifying Policy to say that XSI extensions
are permitted for kill and trap, which not only allows a very specific set
of numeric signals but also allows kill -1 instead of kill -s 1.

The one remaining problem is that some scripts (libtool, I think) trap
SIGPIPE by number, which is not one of the XSI-allowed numeric signals.
I'm not sure if we should make an additional special exception.

Cc'd to the relevant Policy bug.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Michael Meskes
In reply to this post by Adam D. Barratt
On Mon, Jun 23, 2008 at 07:00:13PM +0100, Adam D. Barratt wrote:
> /me coughs in the direction of devscripts' Uploaders field (I'm assuming
> you'd noticed, but just in case :-)

:-)

> Assuming "not-POSIX-but-supported-by-policy" checkbashisms already has a
> flag to indicate whether "echo -n" should be flagged for exactly this
> reason; otherwise it errs on the side of not flagging constructs that
> are policy-compliant.

It does flag both, trap and local. This is how I came to my question.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [hidden email]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Raphael Geissert
In reply to this post by Russ Allbery-2
Russ Allbery wrote:

> "Adam D. Barratt" <[hidden email]> writes:
>
>> Supporting "local x" would be relatively simple; suggestions for a
>> reliable regex to catch use of -a/-o welcome... :)
>
> There was a fairly good one in Lintian that I took out once Policy blessed
> it, or at least we didn't get a lot of false positive reports.
>

Maintainer scripts are fairly simple so I don't think there will be many
false positives ;)

It can't be compared to running the regexps on all the #!/bin/sh scripts
around, right Adam? :)

Cheers,
Raphael


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Raphael Geissert
In reply to this post by Brian M. Carlson
brian m. carlson wrote:
>
> As far as I'm aware, there are three shells in Debian that can be used
> as /bin/sh: bash, dash, and posh[0].  
>

{{b,d}a,{,pd,m}k,z,po}sh, with the 'only' 'problem' that ksh doesn't support
the local keyword, which is mandated by policy. Of course I don't think
anyone wants to set a shell interpreter like zsh as /bin/sh, but it should
be 'safe'.

Cheers,
Raphael


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
In reply to this post by Russ Allbery-2
On Mon, 2008-06-23 at 17:52 -0700, Russ Allbery wrote:
> "Adam D. Barratt" <[hidden email]> writes:
>
> > Supporting "local x" would be relatively simple; suggestions for a
> > reliable regex to catch use of -a/-o welcome... :)
>
> There was a fairly good one in Lintian that I took out once Policy blessed
> it, or at least we didn't get a lot of false positive reports.

Thanks; that looks like it stands a good chance of being resilient.

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
In reply to this post by Raphael Geissert
On Tue, 2008-06-24 at 09:34 -0500, Raphael Geissert wrote:

> Russ Allbery wrote:
>
> > "Adam D. Barratt" <[hidden email]> writes:
> >
> >> Supporting "local x" would be relatively simple; suggestions for a
> >> reliable regex to catch use of -a/-o welcome... :)
> >
> > There was a fairly good one in Lintian that I took out once Policy blessed
> > it, or at least we didn't get a lot of false positive reports.
> >
>
> Maintainer scripts are fairly simple so I don't think there will be many
> false positives ;)

The expression looks fairly robust and passes my testing so far;
admittedly the archive is full of scripts that break almost every
assumption I ever made about shell scripting.

This is getting a little off-topic for -devel I think :)

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
In reply to this post by Michael Meskes
On Tue, 2008-06-24 at 13:36 +0200, Michael Meskes wrote:
> On Mon, Jun 23, 2008 at 07:00:13PM +0100, Adam D. Barratt wrote:
> > Assuming "not-POSIX-but-supported-by-policy" checkbashisms already has a
> > flag to indicate whether "echo -n" should be flagged for exactly this
> > reason; otherwise it errs on the side of not flagging constructs that
> > are policy-compliant.
>
> It does flag both, trap and local. This is how I came to my question.

As per previous messages, the uses of trap flagged aren't policy
compliant; the uses of local being flagged should also be those which
aren't policy compliant - if that's not the case, it's a bug in
checkbashisms.

To be precise, the current tests flag the use of "local foo=bar" and
"local -n foo" as neither is supported by policy; "local x" is permitted
and therefore not flagged.

The next release of checkbashisms will include a "--posix" flag which
will allow the non-POSIX behaviours permitted by policy to be flagged.
Currently neither set of "local" checks flags "local x, y"; I seem to
remember there being a discussion relating to that syntax on the -policy
list a while ago but need to check whether it reached any conclusions.

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Adam D. Barratt
Adam D. Barratt wrote:
[...]
> The next release of checkbashisms will include a "--posix" flag which
> will allow the non-POSIX behaviours permitted by policy to be flagged.
> Currently neither set of "local" checks flags "local x, y"; I seem to
> remember there being a discussion relating to that syntax on the
> -policy list a while ago but need to check whether it reached any
> conclusions.

Actually, ignore that. I was thinking of "local a b" which policy explicitly
says can't be relied upon.

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bashism question

Lars Wirzenius-5
ke, 2008-06-25 kello 08:47 +0100, Adam D. Barratt kirjoitti:

> Adam D. Barratt wrote:
> [...]
> > The next release of checkbashisms will include a "--posix" flag which
> > will allow the non-POSIX behaviours permitted by policy to be flagged.
> > Currently neither set of "local" checks flags "local x, y"; I seem to
> > remember there being a discussion relating to that syntax on the
> > -policy list a while ago but need to check whether it reached any
> > conclusions.
>
> Actually, ignore that. I was thinking of "local a b" which policy explicitly
> says can't be relied upon.

To clarify: is "local foo=bar" policy-compliant or not?

(If not, *sigh*.)



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12