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 "lo
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
> perm
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:
* `local' to create a scoped variable must be supported; however,
`local' may or may not preserve
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
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 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
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" sho
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
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 Po
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
anyon
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 di
"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 lea
"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
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 guarante
In article <[EMAIL PROTECTED]> 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 kern
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 thi
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
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
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
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 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 gu
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, b
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 shor
23 matches
Mail list logo
