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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 <jamessan@debian.org>

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: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 <jamessan@debian.org>

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

In article <20080623080727.GA326@feivel.credativ.de> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

"Adam D. Barratt" <adam@adam-barratt.org.uk> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org