headers
Herbert Xu | 2 Mar 2010 15:39
Picon
Picon

Re: Invalid signal used with trap causes dash to abort

On Wed, Feb 24, 2010 at 10:23:34AM +0000, Peter Kjellerstedt wrote:
> Hi,
> 
> there seems to be a problem  with the trap implementation in dash
> (tested with 0.5.4 and 0.5.5.1). If I specify a signal which is not 
> supported, the shell unconditionally aborts. E.g., I had expected
> the following to print foo (like bash and zsh do):
> 
> # dash -c 'trap "echo trap executed" UNKNOWNSIGNAL || echo "foo"'
> trap: 1: UNKNOWNSIGNAL: bad trap
> 
> This means I cannot write a construct like the following to take 
> advantage of the ERR signal which is present in some shells:
> 
> trap "echo ERR trap executed" ERR 2>/dev/null || :
> 
> I also checked the POSIX documentation, and quoting from
> http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
> (exit status): "For both interactive and non-interactive shells, 
> invalid signal names [XSI] [Option Start] or numbers [Option End] 
> shall not be considered a syntax error and do not cause the shell 
> to abort."

I'll look into this.

Thanks,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Herbert Xu | 9 Mar 2010 05:59
Picon
Picon

Re: dash arithmetic expression bug (1 << 1 + 1 | 1)

On Tue, Mar 09, 2010 at 12:38:54AM +0100, Jilles Tjoelker wrote:
>
> Noncommutative operators break more easily, for example
> Input:
>     echo $((3 - 3 * 3 - 3))
> Expected result:
>     -9
> Actual result:
>     -3

This should fix it:

commit 9655c1ac5646bde1007ecba7c6271d3aa98f294b
Author: Herbert Xu <herbert <at> gondor.apana.org.au>
Date:   Tue Mar 9 12:52:30 2010 +0800

    [ARITH] Fix binary operator parsing

    Jilles Tjoelker reported that binary operator parsing doesn't
    respect operator precedence correctly in the case where a lower-
    precedence operator is followed by a higher-precedence operator,
    and then by a lower-precedence operator.

    This patch fixes this by stopping when we encounter a binary
    oeprator with a precedence lower than one that we have already
    encountered.

    Signed-off-by: Herbert Xu <herbert <at> gondor.apana.org.au>

diff --git a/ChangeLog b/ChangeLog
(Continue reading)

Permalink | Reply | 0 comments |
headers
Herbert Xu | 10 Mar 2010 06:29
Picon
Picon

Re: dash arithmetic expression bug (1 << 1 + 1 | 1)

On Tue, Mar 09, 2010 at 10:33:08PM +0100, Jilles Tjoelker wrote:
> 
> Apart from the compliance issue, it is also bad to expose implementation
> details like the exact meaning of 'noeval' to scripts such that they may
> come to depend on them.

Patch applied.  Thanks a lot!
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Gerrit Pape | 19 Mar 2010 17:20

Re: [PATCH 1/2] [INPUT] exit 127 if command_file is given but does not exist

Hi Herbert,

if you find some spare time, can you please take a look at these
patches, and see whether they're suitable for master?

 http://article.gmane.org/gmane.comp.shells.dash/198
 http://article.gmane.org/gmane.comp.shells.dash/199
 http://article.gmane.org/gmane.comp.shells.dash/200
 http://article.gmane.org/gmane.comp.shells.dash/201
 http://article.gmane.org/gmane.comp.shells.dash/196

Thanks, Gerrit.

On Tue, Sep 29, 2009 at 11:15:55AM +0000, Gerrit Pape wrote:
> This commit makes dash exit with return code 127 instead of 2 if
> started as non-interactive shell with a non-existent command_file
> specified as argument, as documented in
>  http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html#tag_04_128_14
> 
> The wrong exit code was reported by Clint Adams through
>  http://bugs.debian.org/548743
> 
> Signed-off-by: Gerrit Pape <pape <at> smarden.org>
> ---
>  src/input.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/src/input.c b/src/input.c
> index e57ad76..c1e3e54 100644
> --- a/src/input.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron | 21 Mar 2010 16:14
Picon
Favicon

Re: Bug#558989: dash reverses the established logic of test -nt -ot (and maybe others)


Hi Gerrit, Herbert,

On Fri, Mar 19, 2010 at 04:11:46PM +0100, Gerrit Pape wrote:
> severity 558989 important
> tags 558989 + wontfix
> quit
> 
> On Tue, Dec 01, 2009 at 12:43:44PM +1030, Ron wrote:
> > Dash should not implement -nt at all if it wants to be strict about
> > things that aren't POSIX.  If it is going to implement non standard
> > things from other sources, then it absolutely should not be inventing
> > entirely new behaviours for them from whole cloth, let alone completely
> > reversing the logic of existing long established code.
> 
> Hi, here's upstream's opinion on this
>  http://www.mail-archive.com/dash <at> vger.kernel.org/msg00208.html
> 
> I don't think we should make a Debian-specific change for that, hence I
> mark the bug wontfix.

I can sympathise with you not wanting to fork this from upstream (thus
opening a window for ever greater lulz), but if I accept the validity of
Herbert's argument - that this is a BSD shell, with longstanding and
documented behaviour - as a reason not to change this, then doesn't the
very same reasoning at least equally apply to silently changing the
behaviour of the Debian default bin/sh?

He does also say though, that "existing features are not removed unless
there is a very good reason".  Does widely adopting this as a distro
(Continue reading)

Permalink | Reply | 0 comments |

Gmane