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
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
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
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
ke, 2008-06-25 kello 09:18 +0100, Adam D. Barratt kirjoitti:
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.
I
Lars Wirzenius wrote:
ke, 2008-06-25 kello 09:18 +0100, Adam D. Barratt kirjoitti:
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
Russ Allbery wrote:
Adam D. Barratt [EMAIL PROTECTED] 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
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
On Mon, 2008-06-23 at 17:52 -0700, Russ Allbery wrote:
Adam D. Barratt [EMAIL PROTECTED] 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
On Tue, 2008-06-24 at 09:34 -0500, Raphael Geissert wrote:
Russ Allbery wrote:
Adam D. Barratt [EMAIL PROTECTED] 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
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
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,
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
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.
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
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
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
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
Adam D. Barratt [EMAIL PROTECTED] 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
brian m. carlson [EMAIL PROTECTED] 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
20 matches
Mail list logo
