"brian m. carlson" <sandals@crustytoothpaste.ath.cx> 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 (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

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: 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

Russ Allbery wrote:

> "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.
>

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

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

On Mon, 2008-06-23 at 17:52 -0700, Russ Allbery wrote:
> "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.

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

Adam


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

On Tue, 2008-06-24 at 09:34 -0500, Raphael Geissert wrote:
> Russ Allbery wrote:
>
> > "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.
> >
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

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

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

Lars Wirzenius wrote:

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

(If not, *sigh*.)


To the best of my knowledge, no, it's not compliant. The relevant section
reads:


<snip>
* `local' to create a scoped variable must be supported; however,
`local' may or may not preserve the variable value from an outer
scope and may or may not support arguments more complex than
simple variables. Only uses such as:
fname () {
local a
a='
# ... use a ...
}
must be supported.
<snip>

As "foo=bar" is an argument "more complex than simple variables" and the
example explicitly shows the use of local to declare the variable followed
by assignment to it, my reading of policy is that "local foo=bar" is not
permitted.


Adam



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