zsh-workers
 help / color / mirror / code / Atom feed
* execve bug
@ 1999-06-14 20:13 David Aspinwall
  1999-06-16  6:42 ` Bart Schaefer
  1999-06-16  6:56 ` PATCH: " Bart Schaefer
  0 siblings, 2 replies; 4+ messages in thread
From: David Aspinwall @ 1999-06-14 20:13 UTC (permalink / raw)
  To: amol, zsh-workers

This is a bug which shows up in the NT port (based no 3.0.5).
It isn't in the NT-specific code, though, and I think would happen on
any system which doesn't support #!, so I'm sending it to zsh-workers
too.

If you have a script called 'dog' whose first line is '#!/bin/sh '
(i.e., has at least one space after the interpreter name), and
the OS doesn't support #!, zsh will wind up calling execve with
an argv of ("/bin/sh", "", "dog").  You get an error like
: : No such file or directory
or if you have multiple spaces,
 :  : Permission denied

Here's a patch to exec.c against 3.0.5 (or at least the version
in the zshsrc file for the NT distribution).


*** ../../zsh-orig/Src/exec.c	Wed May 19 16:16:26 1999
--- exec.c	Fri Jun 11 13:45:06 1999
***************
*** 180,187 ****
  		if (execvebuf[0] == '#') {
  		    if (execvebuf[1] == '!') {
  			for (t0 = 0; t0 != ct; t0++)
! 			    if (execvebuf[t0] == '\n')
  				execvebuf[t0] = '\0';
  			execvebuf[POUNDBANGLIMIT] = '\0';
  			for (ptr = execvebuf + 2; *ptr && *ptr == ' '; ptr++);
  			for (ptr2 = ptr; *ptr && *ptr != ' '; ptr++);
--- 180,196 ----
  		if (execvebuf[0] == '#') {
  		    if (execvebuf[1] == '!') {
  			for (t0 = 0; t0 != ct; t0++)
! 			    if (execvebuf[t0] == '\n') {
  				execvebuf[t0] = '\0';
+ 				/* get rid of trailing spaces */
+ 				for (--t0; t0 > 1; --t0) {
+ 				  if (execvebuf[t0] == ' ') {
+ 				    execvebuf[t0] = '\0';
+ 				  } else {
+ 				    break;
+ 				  }
+ 				}
+ 			    }
  			execvebuf[POUNDBANGLIMIT] = '\0';
  			for (ptr = execvebuf + 2; *ptr && *ptr == ' '; ptr++);
  			for (ptr2 = ptr; *ptr && *ptr != ' '; ptr++);


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: execve bug
  1999-06-14 20:13 execve bug David Aspinwall
@ 1999-06-16  6:42 ` Bart Schaefer
  1999-06-16  6:56 ` PATCH: " Bart Schaefer
  1 sibling, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 1999-06-16  6:42 UTC (permalink / raw)
  To: David Aspinwall, amol, zsh-workers

On Jun 14,  1:13pm, David Aspinwall wrote:
} Subject: execve bug
}
} If you have a script called 'dog' whose first line is '#!/bin/sh '
} (i.e., has at least one space after the interpreter name), and
} the OS doesn't support #!, zsh will wind up calling execve with
} an argv of ("/bin/sh", "", "dog").

Thanks for pointing this out.  The same problem happens with a trailing
tab, so I think the following patch is better.  There was also no reason
for the old code wandereding all the way to t0 == ct clobbering newlines
once the first one was found.

Index: Src/exec.c
==========================================================================
@@ -251,7 +251,9 @@
 		    if (execvebuf[1] == '!') {
 			for (t0 = 0; t0 != ct; t0++)
 			    if (execvebuf[t0] == '\n')
-				execvebuf[t0] = '\0';
+				break;
+			while (inblank(execvebuf[t0]))
+			    execvebuf[t0--] = '\0';
 			execvebuf[POUNDBANGLIMIT] = '\0';
 			for (ptr = execvebuf + 2; *ptr && *ptr == ' '; ptr++);
 			for (ptr2 = ptr; *ptr && *ptr != ' '; ptr++);

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 4+ messages in thread

* PATCH: Re: execve bug
  1999-06-14 20:13 execve bug David Aspinwall
  1999-06-16  6:42 ` Bart Schaefer
@ 1999-06-16  6:56 ` Bart Schaefer
  1999-06-16  8:51   ` PATCH: pws-22: " Peter Stephenson
  1 sibling, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 1999-06-16  6:56 UTC (permalink / raw)
  To: zsh-workers

(I inadvertently sent another copy of this though math.gatech.edu because
that's where David sent the mail to which I replied.  My other doesn't have
the word "PATCH" in the header, and hasn't come back to me yet, so on the
chance that it's been hung out in limbo I'm sending this one.)

On Jun 14,  1:13pm, David Aspinwall wrote:
} Subject: execve bug
}
} If you have a script called 'dog' whose first line is '#!/bin/sh '
} (i.e., has at least one space after the interpreter name), and
} the OS doesn't support #!, zsh will wind up calling execve with
} an argv of ("/bin/sh", "", "dog").

Thanks for pointing this out.  The same problem happens with a trailing
tab, so I think the following patch is better.  There was also no reason
for the old code wandereding all the way to t0 == ct clobbering newlines
once the first one was found.

Index: Src/exec.c
==========================================================================
@@ -251,7 +251,9 @@
 		    if (execvebuf[1] == '!') {
 			for (t0 = 0; t0 != ct; t0++)
 			    if (execvebuf[t0] == '\n')
-				execvebuf[t0] = '\0';
+				break;
+			while (inblank(execvebuf[t0]))
+			    execvebuf[t0--] = '\0';
 			execvebuf[POUNDBANGLIMIT] = '\0';
 			for (ptr = execvebuf + 2; *ptr && *ptr == ' '; ptr++);
 			for (ptr2 = ptr; *ptr && *ptr != ' '; ptr++);

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 4+ messages in thread

* PATCH: pws-22: Re: execve bug
  1999-06-16  6:56 ` PATCH: " Bart Schaefer
@ 1999-06-16  8:51   ` Peter Stephenson
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Stephenson @ 1999-06-16  8:51 UTC (permalink / raw)
  To: zsh-workers

"Bart Schaefer" wrote:
> On Jun 14,  1:13pm, David Aspinwall wrote:
> } Subject: execve bug
> }
> } If you have a script called 'dog' whose first line is '#!/bin/sh '
> } (i.e., has at least one space after the interpreter name), and
> } the OS doesn't support #!, zsh will wind up calling execve with
> } an argv of ("/bin/sh", "", "dog").
> 
> Thanks for pointing this out.  The same problem happens with a trailing
> tab, so I think the following patch is better.  There was also no reason
> for the old code wandereding all the way to t0 == ct clobbering newlines
> once the first one was found.

This is needed in 3.1.5 as well and applies with a bit of offset.

This reminds me... One of my colleagues in Zeuthen complained to me about
something similar a couple of years ago (with the usual complaints about
how everything was becoming incompatible and it was a crying shame, etc.)
and I sent a patch.  The problem was this:

% cat tst
#!/home/user2/pws/bin/zsh  -f        
#                            ^^^^^^^^spaces here
print "hello, world"
% ./tst
zsh: bad option: - 

and I've discovered Bart's reply to it in 2797 (why not the original
message or my followup? is the archive smart enough to know they appear as
links?) and hence my reply to that in 2798.

We sort of agreed on Bart's (3):

> 2.  Stop parsing options at whitespace, and completely ignore it and
>     all the characters that come after it.  I believe BSD 4.2 csh did
>     this, if I'm remembering correctly my early days of feeling my way
>     through scripting.
> 
> 3.  As (2), but issue an error if there's anything other than whitespace
>     in the trailing part.  I think this is the most reasonable choice, as
>     it doesn't silently drop stuff from the #! line (which was mystifying
>     when it happened in csh, which is why I'm pretty sure I remember it).

However, the patch got ignored.  Here's a new version which won't be ---
unless anyone can think of a good reason why it would be safer simply to
report a better error.  This should presumably fit seamlessly into 3.0.6,
apart from massaging the documentation (and in certain quarters it will be
regarded as a bug fix).

--- Doc/Zsh/options.yo.spc	Fri Jun 11 13:36:55 1999
+++ Doc/Zsh/options.yo	Wed Jun 16 10:37:25 1999
@@ -34,6 +34,12 @@
 in which case the inversion of that name refers to the option being on.
 For example, `tt(PLUS()n)' is the short name of `tt(exec)', and
 `tt(-n)' is the short name of its inversion, `tt(noexec)'.
+
+In strings of single letter options supplied to the shell at startup,
+trailing whitespace will be ignored; for example the string `tt(-f    )'
+will be treated just as `tt(-f)', but the string `tt(-f i)' is an error.
+This is because many systems which implement the `tt(#!)' mechanism for
+calling scripts do not strip trailing whitespace.
 texinode(Description of Options)(Option Aliases)(Specifying Options)(Options)
 sect(Description of Options)
 cindex(options, description)
--- Src/init.c.spc	Mon Jun 14 17:39:43 1999
+++ Src/init.c	Wed Jun 16 10:33:12 1999
@@ -194,6 +194,7 @@
 
     /* loop through command line options (begins with "-" or "+") */
     while (*argv && (**argv == '-' || **argv == '+')) {
+	char *args = *argv;
 	action = (**argv == '-');
 	if(!argv[0][1])
 	    *argv = "--";
@@ -228,6 +229,14 @@
 		    restricted = action;
 		else
 		    dosetopt(optno, action, 1);
+              break;
+	    } else if (isspace(**argv)) {
+		/* zsh's typtab not yet set, have to use ctype */
+		while (*++*argv)
+		    if (!isspace(**argv)) {
+			zerr("bad option string: `%s'", args, 0);
+			exit(1);
+		    }
 		break;
 	    } else {
 	    	if (!(optno = optlookupc(**argv))) {

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1999-06-18  8:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-14 20:13 execve bug David Aspinwall
1999-06-16  6:42 ` Bart Schaefer
1999-06-16  6:56 ` PATCH: " Bart Schaefer
1999-06-16  8:51   ` PATCH: pws-22: " Peter Stephenson

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).