Parse errors don't cause a non-zero exit code?

Parse errors don't cause a non-zero exit code?

[Dan Nelson]

$ echo "'" > /tmp/test ; zsh -f /tmp/test ; echo $?
/tmp/test:2: unmatched '
0

ksh93, ash, and bash all return non-zero here, and it looks like
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08
wants a non-zero result also.

A co-worker asked about it because he wanted to use "zsh -n" to test
user-submitted scripts for silly typos before running them.  Checking
for output on stderr is a workaround.

A related comment: The zsh documentation uses all six combinations of
"{exit,return} {code,value,status}", making it hard to search :(

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Parse errors don't cause a non-zero exit code?

[Dan Nelson]

In the last episode (Mar 29), Dan Nelson said:
> $ echo "'" > /tmp/test ; zsh -f /tmp/test ; echo $?
> /tmp/test:2: unmatched '
> 0
> 
> ksh93, ash, and bash all return non-zero here, and it looks like
> http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08
> wants a non-zero result also.

I'm thinking something like this, but I don't know enough about zsh
internals to say that propagating errflag into lastval here is the
right fix.  It doesn't break the testsuite at least:

--- Src/init.c~	Thu Mar 31 00:49:30 2005
+++ Src/init.c	Thu Mar 31 00:49:30 2005
@@ -983,6 +983,8 @@ init_misc(void)
 	bshin = fdopen(SHIN, "r");
 	execstring(cmd, 0, 1);
 	stopmsg = 1;
+	if (errflag)
+		lastval = errflag;
 	zexit(lastval, 0);
     }
 
@@ -1277,6 +1277,8 @@ zsh_main(UNUSED(int argc), char **argv)
 	while (tok != ENDINPUT && (tok != LEXERR || isset(SHINSTDIN)));
 	if (tok == LEXERR) {
 	    stopmsg = 1;
+	    if (errflag)
+	    	lastval = errflag;
 	    zexit(lastval, 0);
 	}
 	if (!(isset(IGNOREEOF) && interact)) {
--- Src/lex.c~	Thu Mar 31 00:58:03 2005
+++ Src/lex.c	Thu Mar 31 00:58:03 2005
@@ -330,7 +330,6 @@ lexrestore(void)
     ecssub = lstack->ecssub;
     ecnfunc = lstack->ecnfunc;
     hlinesz = lstack->hlinesz;
-    errflag = 0;
 
     ln = lstack->next;
     free(lstack);


-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Parse errors don't cause a non-zero exit code?

[Peter Stephenson]

Dan Nelson wrote:
> In the last episode (Mar 29), Dan Nelson said:
> > $ echo "'" > /tmp/test ; zsh -f /tmp/test ; echo $?
> > /tmp/test:2: unmatched '
> > 0
> > 
> > ksh93, ash, and bash all return non-zero here, and it looks like
> > http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag
> _02_08
> > wants a non-zero result also.
> 
> I'm thinking something like this, but I don't know enough about zsh
> internals to say that propagating errflag into lastval here is the
> right fix.  It doesn't break the testsuite at least:

I came up with this.  It uses the LEXERR to signal the error rather than
propagating errflag.

I found there was another case which still didn't return non-zero
status, when the same code came from stdin.  That needed handling at the
next level down.

I've added tests for both.

Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.49
diff -u -r1.49 init.c
--- Src/init.c	31 Mar 2005 09:54:59 -0000	1.49
+++ Src/init.c	1 Apr 2005 10:02:41 -0000
@@ -131,6 +131,8 @@
 		(tok == LEXERR && (!isset(SHINSTDIN) || !toplevel)) ||
 		justonce)
 		break;
+	    if (tok == LEXERR && !lastval)
+		lastval = 1;
 	    continue;
 	}
 	if (hend(prog)) {
@@ -1282,6 +1284,9 @@
 	    loop(1,0);
 	while (tok != ENDINPUT && (tok != LEXERR || isset(SHINSTDIN)));
 	if (tok == LEXERR) {
+	    /* Make sure a parse error exits with non-zero status */
+	    if (!lastval)
+		lastval = 1;
 	    stopmsg = 1;
 	    zexit(lastval, 0);
 	}
Index: Test/A01grammar.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A01grammar.ztst,v
retrieving revision 1.9
diff -u -r1.9 A01grammar.ztst
--- Test/A01grammar.ztst	22 Jun 2004 13:10:02 -0000	1.9
+++ Test/A01grammar.ztst	1 Apr 2005 10:02:41 -0000
@@ -7,6 +7,7 @@
   mkdir basic.tmp && cd basic.tmp
 
   touch foo bar
+  echo "'" >unmatched_quote.txt
 
 %test
 #
@@ -439,3 +440,11 @@
   done || print no
 0:Handling of &&'s and ||'s with a for loop in between
 >no
+
+  $ZTST_testdir/../Src/zsh -f unmatched_quote.txt
+1:Parse error with file causes non-zero exit status
+?unmatched_quote.txt:2: unmatched '
+
+  $ZTST_testdir/../Src/zsh -f <unmatched_quote.txt
+1:Parse error on standard input causes non-zero exit status
+?zsh: unmatched '

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Parse errors don't cause a non-zero exit code?

[Dan Nelson]

In the last episode (Apr 01), Peter Stephenson said:
> Dan Nelson wrote:
> > In the last episode (Mar 29), Dan Nelson said:
> > > $ echo "'" > /tmp/test ; zsh -f /tmp/test ; echo $?
> > > /tmp/test:2: unmatched '
> > > 0
> 
> I came up with this.  It uses the LEXERR to signal the error rather
> than propagating errflag.
> 
> I found there was another case which still didn't return non-zero
> status, when the same code came from stdin.  That needed handling at
> the next level down.

There's a third case: input passed via -c.  Possible fix and testcase. 

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.85
diff -u -p -r1.85 exec.c
--- Src/exec.c	31 Mar 2005 09:54:59 -0000	1.85
+++ Src/exec.c	1 Apr 2005 19:56:59 -0000
@@ -162,6 +162,8 @@ parse_string(char *s)
     lineno = 1;
     p = parse_list();
     lineno = oldlineno;
+    if (tok == LEXERR && !lastval)
+	lastval = 1;
     strinend();
     inpop();
     lexrestore();
Index: Test/A01grammar.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A01grammar.ztst,v
retrieving revision 1.10
diff -u -p -r1.10 A01grammar.ztst
--- Test/A01grammar.ztst	1 Apr 2005 10:17:25 -0000	1.10
+++ Test/A01grammar.ztst	1 Apr 2005 19:56:59 -0000
@@ -448,3 +448,7 @@
   $ZTST_testdir/../Src/zsh -f <unmatched_quote.txt
 1:Parse error on standard input causes non-zero exit status
 ?zsh: unmatched '
+
+  $ZTST_testdir/../Src/zsh -f -c "'"
+1:Parse error on inline command causes non-zero exit status
+?zsh: unmatched '


-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Parse errors don't cause a non-zero exit code?

[Peter Stephenson]

Dan Nelson wrote:
> A related comment: The zsh documentation uses all six combinations of
> "{exit,return} {code,value,status}", making it hard to search :(

I've committed a very dull patch to standardise on "status" for return
and exit statuses.

It's still not completely consistent about distinguishing an exit status
(the value returned by a command as seen by the caller) from a return
status (the value returned by a function or builtin as seen by the
command itself), but that would take more thought; what's more, "the
builtin/function returns status X" is a perfectly natural way of saying
"returns the exit status X" given that the command doesn't actually exit
(in the UNIX sense).  In other words, I don't think I want to play any
more.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Parse errors don't cause a non-zero exit code?

[Felipe Kellermann]

On Fri, 1 Apr 2005 1:08pm  +0100, Peter Stephenson wrote:

> builtin/function returns status X" is a perfectly natural way of saying
> "returns the exit status X" given that the command doesn't actually exit
> (in the UNIX sense).  In other words, I don't think I want to play any
> more.

Hi Peter,

About this issue, I have a long-term question about the exit status of zsh 
when it gets passed an script as argument:

% zsh a
a: can't open input file: a
% print $?
1
% a
zsh: command not found: a
% print $?
127
%

I am aware that the standard isn't very clear in this respect, but most 
shells explicitly interpret both cases the same way, returning 127 when 
the shell gets a command as an argument.

$ ksh --version
  version         sh (AT&T Labs Research) 1993-12-28 q
$ ksh a
ksh: line 1: a: not found
$ echo $?
127
$

$ bash --version
GNU bash, version 3.00.0(1)-release (i586-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
$ bash a
bash: a: No such file or directory
$ echo $?
127
$

I have recently talked with Michael Rendell about this issue on pdksh and 
he OK'ed the patch I sent to him, though he is not planning to make a new 
release of pdksh :-)

-- 
Felipe Kellermann

Re: Parse errors don't cause a non-zero exit code?

[Peter Stephenson]

Felipe Kellermann wrote:
> About this issue, I have a long-term question about the exit status of zsh 
> when it gets passed an script as argument:
> 
> % zsh a
> a: can't open input file: a
> % print $?
> 1
> % a
> zsh: command not found: a
> % print $?
> 127
> %
> 
> I am aware that the standard isn't very clear in this respect, but most 
> shells explicitly interpret both cases the same way, returning 127 when 
> the shell gets a command as an argument.

Well, it's a script rather than a command, but it looks like other
shells don't seem to worry about the distinction here.

This is easy to fix.  In this case returning status 126 for a file that's
not executable doesn't make sense, so I haven't tested for it in the way
that's done in other places.

I've also modified it so that the error message is a bit more sensible.
Before you would get

NonExistentScript: can't open input file: NonExistentScript

which looks a little silly.  Now the first name is the full path to the
zsh executable, which also agrees with other shells.

Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.50
diff -u -r1.50 init.c
--- Src/init.c	1 Apr 2005 10:17:24 -0000	1.50
+++ Src/init.c	11 Apr 2005 10:05:33 -0000
@@ -308,14 +308,14 @@
     }
     if (*argv) {
 	if (unset(SHINSTDIN)) {
-	    argzero = *argv;
 	    if (!cmd)
-		SHIN = movefd(open(unmeta(argzero), O_RDONLY | O_NOCTTY));
+		SHIN = movefd(open(unmeta(*argv), O_RDONLY | O_NOCTTY));
 	    if (SHIN == -1) {
-		zerr("can't open input file: %s", argzero, 0);
-		exit(1);
+		zerr("can't open input file: %s", *argv, 0);
+		exit(127);
 	    }
 	    opts[INTERACTIVE] &= 1;
+	    argzero = *argv;
 	    argv++;
 	}
 	while (*argv)
Index: Test/A01grammar.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A01grammar.ztst,v
retrieving revision 1.11
diff -u -r1.11 A01grammar.ztst
--- Test/A01grammar.ztst	4 Apr 2005 09:35:43 -0000	1.11
+++ Test/A01grammar.ztst	11 Apr 2005 10:05:33 -0000
@@ -452,3 +452,7 @@
   $ZTST_testdir/../Src/zsh -f -c "'"
 1:Parse error on inline command causes non-zero exit status
 ?zsh: unmatched '
+
+  $ZTST_testdir/../Src/zsh -f NonExistentScript
+127q:Non-existent script causes exit status 127
+?$ZTST_testdir/../Src/zsh: can't open input file: NonExistentScript

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************