headers
Jilles Tjoelker | 5 Jun 2010 18:06
Picon
Favicon

debian patches to exit with code 127 for nonexistent/directory scripts

Debian's dash package has some local changes which cause an exit with
code 127, as required by POSIX, if a script (passed with dash
<filename>) cannot be opened or cannot be read because it is a
directory.

Unfortunately, these patches also affect the . builtin (if the pathname
contains a slash) and use EXEXIT, which means such errors always cause
the shell to exit, even in interactive mode or if the builtin's
specialness has been disabled using command.

% dash
$ . ./nonexistent
.: 1: Can't open ./nonexistent
zsh: exit 127   dash
%

% dash -c 'command . ./nonexistent; echo continued'

Note: Do not compare this with bash. Bash deliberately does not follow
POSIX XCU 2.8.1 Consequences of Shell Errors if not in POSIX mode, and
even in POSIX mode trying to source a nonexistent dot script (without
slash in the pathname) fails to abort the shell.

Note 2: POSIX seems unclear about what 'command .' should do, but is
very clear that failure to find/read a dot script shall not cause an
interactive shell to exit.

--

-- 
Jilles Tjoelker
--
(Continue reading)

Permalink | Reply | 30 comments |
headers
Herbert Xu | 8 Jun 2010 12:19
Picon
Picon

Re: debian patches to exit with code 127 for nonexistent/directory scripts

Jilles Tjoelker <jilles <at> stack.nl> wrote:
> Debian's dash package has some local changes which cause an exit with
> code 127, as required by POSIX, if a script (passed with dash
> <filename>) cannot be opened or cannot be read because it is a
> directory.

Please report this through Debian's bug tracking system.

There is nothing that I can do about 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/
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 | 2 comments |
headers
Cristian Ionescu-Idbohrn | 8 Jun 2010 12:36
Picon
Favicon

Re: debian patches to exit with code 127 for nonexistent/directory scripts

On Tue, 8 Jun 2010, Herbert Xu wrote:

> Jilles Tjoelker <jilles <at> stack.nl> wrote:
> > Debian's dash package has some local changes which cause an exit
> > with code 127, as required by POSIX, if a script (passed with dash
> > <filename>) cannot be opened or cannot be read because it is a
> > directory.

My interpretation of the above is that debian's patched dash is POSIX
compliant WRT the named exit code.

> Please report this through Debian's bug tracking system.

Why?

> There is nothing that I can do about this.

Upstream dash is _not_ POSIX compliant WRT the named exit code, seems
to be the meaning of the sentence.  And you can certainly _do_
something about it.

On the other hand, I may have got it all wrong (because of some
language barrier), in which case please accept my apologies.

Cheers,

--

-- 
Cristian
--
To unsubscribe from this list: send the line "unsubscribe dash" in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Herbert Xu | 11 Jun 2010 10:39
Picon
Picon

Re: debian patches to exit with code 127 for nonexistent/directory scripts

Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn <at> axis.com> wrote:
> On Tue, 8 Jun 2010, Herbert Xu wrote:
> 
>> Jilles Tjoelker <jilles <at> stack.nl> wrote:
>> > Debian's dash package has some local changes which cause an exit
>> > with code 127, as required by POSIX, if a script (passed with dash
>> > <filename>) cannot be opened or cannot be read because it is a
>> > directory.
> 
> My interpretation of the above is that debian's patched dash is POSIX
> compliant WRT the named exit code.

Well if dash is broken then you should submit a patch.

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/
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 | 14 Jun 2010 11:54

[PATCH] [INPUT] exit 127 if command_file is given but doesn't exist

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 (or a directory), 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 and Jari Aalto through
 http://bugs.debian.org/548743
 http://bugs.debian.org/548687

Signed-off-by: Gerrit Pape <pape <at> smarden.org>
---

On Sat, Jun 05, 2010 at 06:06:51PM +0200, Jilles Tjoelker wrote:
> Debian's dash package has some local changes which cause an exit with
> code 127, as required by POSIX, if a script (passed with dash
> <filename>) cannot be opened or cannot be read because it is a
> directory.
>
> Unfortunately, these patches also affect the . builtin (if the
> pathname
> contains a slash) and use EXEXIT, which means such errors always cause
> the shell to exit, even in interactive mode or if the builtin's
> specialness has been disabled using command.

Hi Jilles, thanks for the hint, I didn't notice.  I hope this patch does
better, it replaces these two
 http://article.gmane.org/gmane.comp.shells.dash/198
 http://article.gmane.org/gmane.comp.shells.dash/199

Regards, Gerrit.
(Continue reading)

Permalink | Reply | 26 comments |
headers
Gerrit Pape | 14 Jun 2010 11:56

[PATCH] [EVAL] with set -e exit the shell if a subshell exits non-zero

Example:

$ dash -c 'set -e; (false); echo here'
here

With this commit, dash exits 1 before echo.

The bug was reported by Stefan Fritsch through
 http://bugs.debian.org/514863

Signed-off-by: Gerrit Pape <pape <at> smarden.org>
---
 src/eval.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/eval.c b/src/eval.c
index 439f881..a0d0f3b 100644
--- a/src/eval.c
+++ b/src/eval.c
 <at>  <at>  -251,6 +251,8  <at>  <at>  checkexit:
 	case NSUBSHELL:
 	case NBACKGND:
 		evalfn = evalsubshell;
+		if (eflag && !(flags & EV_TESTED))
+			checkexit = ~0;
 		goto calleval;
 	case NPIPE:
 		evalfn = evalpipe;
--

-- 
1.6.0.3
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gerrit Pape | 14 Jun 2010 11:56

[PATCH] [EVAL] don't clear eflag when forking subshell

According to
 http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_12
"A subshell environment shall be created as a duplicate of the shell
environment, except that signal traps set by that shell environment
shall be set to the default values."

Currently the eflag is cleared when forking a subshell, e.g.

$ dash -c 'set -e ; z=$(false;echo foo) ; echo $z'
foo

With this commit the eflag is preserved for subshells, and dash exits 1
before echo.

The problem was reported by Vincent Lefevre through
 http://bugs.debian.org/514863

Signed-off-by: Gerrit Pape <pape <at> smarden.org>
---
 src/eval.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/eval.c b/src/eval.c
index a0d0f3b..bd4b485 100644
--- a/src/eval.c
+++ b/src/eval.c
 <at>  <at>  -627,7 +627,6  <at>  <at>  evalbackcmd(union node *n, struct backcmd *result)
 				dup2(pip[1], 1);
 				close(pip[1]);
 			}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Koropoff | 16 Jun 2010 04:14
Picon

DASH regression

Hello,
    I encountered a regression in DASH from git while attempting to get
it working on Solaris.  I got it to build and run, but my scripts were
mysteriously failing.  I tracked it down to a logic bug in setvareq()
that caused it to assign through the wrong pointer when attempting to
remove a variable from its hash bucket.  The following test case
reproduces the bug for me:

--

#!/bin/dash
GDM_LANG="bar"
OPTION="foo"
unset GDM_LANG
# OPTION has mysteriously become unset
echo "$OPTION"

--

I'll follow up with a patch.

Regards,
Brian Koropoff

--
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Koropoff | 16 Jun 2010 04:29
Picon

[PATCH] Fix regression when unsetting variables.

When removing a variable from its hash chain, assign to the 'next' pointer
of the previous link rather than the hash bucket.
---
 src/var.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/var.c b/src/var.c
index f456fbd..c0e5706 100644
--- a/src/var.c
+++ b/src/var.c
 <at>  <at>  -238,11 +238,11  <at>  <at>  intmax_t setvarint(const char *name, intmax_t val, int flags)
 void
 setvareq(char *s, int flags)
 {
-	struct var *vp, **vpp;
+	struct var *vp, **vpp, **fvpp;

 	vpp = hashvar(s);
 	flags |= (VEXPORT & (((unsigned) (1 - aflag)) - 1));
-	vp = *findvar(vpp, s);
+	vp = *(fvpp = findvar(vpp, s));
 	if (vp) {
 		if (vp->flags & VREADONLY) {
 			const char *n;
 <at>  <at>  -265,7 +265,7  <at>  <at>  setvareq(char *s, int flags)

 		if (((flags & (VEXPORT|VREADONLY|VSTRFIXED|VUNSET)) |
 		     (vp->flags & VSTRFIXED)) == VUNSET) {
-			*vpp = vp->next;
+			*fvpp = vp->next;
(Continue reading)

Permalink | Reply | 1 comment |

Gmane