/bin/zsh -ce 'false; echo bug'

/bin/zsh -ce 'false; echo bug'

[Matt Watson]

gnumake-3.74 wants to use "/bin/sh -ce <commandstring>" to exec a sub  
make. Unfortunately if zsh == sh, zsh doesn't grok the -ce as separate  
options, so it ignores the "e" and does not set ERREXIT.

Should it? Has anyone else come across this?

matt.

Re: /bin/zsh -ce 'false; echo bug'

[Owen M. Astley]

On Wed, 25 Aug 1999, Matt Watson wrote:

> gnumake-3.74 wants to use "/bin/sh -ce <commandstring>" to exec a sub  
> make. Unfortunately if zsh == sh, zsh doesn't grok the -ce as separate  
> options, so it ignores the "e" and does not set ERREXIT.
> 
> Should it? Has anyone else come across this?

I 'think' that POSIX doesn't allow for options of this type, it should be
written as -c -e <commandstring>.  However, I can't remember where I  read
that, and as most shells seem to cope with it, it should be done.

Is there any reason why parseargs() doesn't use getopt?

Owen

Re: /bin/zsh -ce 'false; echo bug'

[Bart Schaefer]

On Aug 26,  9:26am, Owen M. Astley wrote:
> Subject: Re: /bin/zsh -ce 'false; echo bug'
> On Wed, 25 Aug 1999, Matt Watson wrote:
> 
> > gnumake-3.74 wants to use "/bin/sh -ce <commandstring>" to exec a sub  
> > make. Unfortunately if zsh == sh, zsh doesn't grok the -ce as separate  
> > options, so it ignores the "e" and does not set ERREXIT.
> 
> I 'think' that POSIX doesn't allow for options of this type, it should be
> written as -c -e <commandstring>.

Zsh interprets everything after the -c as part of the command, so that will
attempt to run a command named "-e".  If it really is the case that the
order of option letters doesn't matter (which appears to be true of bash,
at least), then zsh's option parser needs a bit more of a workover.

PATCH: Re: /bin/zsh -ce 'false; echo bug'

[Bart Schaefer]

On Aug 26,  6:06pm, Bart Schaefer wrote:
> Subject: Re: /bin/zsh -ce 'false; echo bug'
> On Aug 26,  9:26am, Owen M. Astley wrote:
> > Subject: Re: /bin/zsh -ce 'false; echo bug'
> > On Wed, 25 Aug 1999, Matt Watson wrote:
> > 
> > > gnumake-3.74 wants to use "/bin/sh -ce <commandstring>"
> > 
> > I 'think' that POSIX doesn't allow for options of this type, it should be
> > written as -c -e <commandstring>.
> 
> Zsh interprets everything after the -c as part of the command, so that will
> attempt to run a command named "-e".

Here's a patch against 3.0.6, which should also apply to 3.1.6, to make
zsh's behavior consistent with bash's in this instance.  If you really want
to run a command named "-e" (or anything else starting with - or +), after
this patch you need one of

	zsh -cb ...
	zsh -c -b ...
	zsh -c- ...
	zsh -c - ...
	zsh -c -- ...

where "-b" is of course the csh-ism for "--".  It previously was neither
necessary nor possible to combine -b and -c in any order (whichever came
first was the only one interpreted).

I await word from the more extensively POSIXified readers on whether this
patch should be officially included.

Index: Src/init.c
===================================================================
@@ -236,14 +236,9 @@
 	    }
 
 	    if (**argv == 'c') {         /* -c command */
-		if (!*++argv) {
-		    zerr("string expected after -c", NULL, 0);
-		    exit(1);
-		}
-		cmd = *argv++;
+		cmd = *argv;
 		opts[INTERACTIVE] &= 1;
 		opts[SHINSTDIN] = 0;
-		goto doneoptions;
 	    } else if (**argv == 'o') {
 		if (!*++*argv)
 		    argv++;
@@ -276,6 +271,13 @@
     }
     doneoptions:
     paramlist = newlinklist();
+    if (cmd) {
+	if (!*argv) {
+	    zerr("string expected after -%s", cmd, 0);
+	    exit(1);
+	}
+	cmd = *argv++;
+    }
     if (*argv) {
 	if (unset(SHINSTDIN)) {
 	    argzero = *argv;