* #! problem @ 1997-01-15 9:37 Peter Stephenson 1997-01-15 18:50 ` Bart Schaefer 0 siblings, 1 reply; 3+ messages in thread From: Peter Stephenson @ 1997-01-15 9:37 UTC (permalink / raw) To: Zsh hackers list Somebody here tried something like: #!/bin/zsh -f # ^^^^empty spaces added here echo your code here and got back: /bin/zsh: bad option: - This is a problem because, once again, previous versions of zsh weren't so fussy. (For comparison, ksh reacts similarly but you get `-f : bad option(s)' which is at least a little clearer.) This happens on IRIX, SunOS 4, AIX and Digital Unix 4.0, though apparently not on Solaris. I would think dropping meaningless spaces in an option string (i.e. when an option letter is expected) again would be harmless. I just want to wait for the waves of protest before trying anything. -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: #! problem 1997-01-15 9:37 #! problem Peter Stephenson @ 1997-01-15 18:50 ` Bart Schaefer 1997-01-16 9:37 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: Bart Schaefer @ 1997-01-15 18:50 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On Jan 15, 10:37am, Peter Stephenson wrote: } Subject: #! problem } } Somebody here tried something like: } } #!/bin/zsh -f } # ^^^^empty spaces added here As opposed to ... full spaces? } I would think dropping meaningless spaces in an option string } (i.e. when an option letter is expected) again would be harmless. } I just want to wait for the waves of protest before trying anything. I don't think *dropping* them is the right idea; that could be pretty confusing, couldn't it? I'd say that a space where an option letter was expected was actually pretty meaning*ful* -- it probably means that somebody meant to pass two words to the shell, but mistakenly passed only one. Possible solutions: 1. Improve the error message. /bin/zsh: bad option character " " in: - (There's probably a better improvement.) 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). 4. Assume that if whitespace makes it to the option parser, there were really supposed to be two arguments, and actually arrange to parse it that way, i.e. split the word into two at the whitespace. I don't really think this is a viable solution, not only because it violates the whole principle of #! lines (one path plus one argument), but because it also could mean arbitrarily increasing the number of words in argv. On the other hand, it makes this work as it appears that it should: #! /bin/zsh -f -v -x 5. Ignore whitespace only if it's followed by a `-' and ignore that `-' as well; otherwise act like (2). This also makes "-f -v -x" and the like work, but doesn't have the other disadvantages of (4). It still makes zsh a bit mysterious with respect to other programs named on #! lines, though, so it's probably not something we should do. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: #! problem 1997-01-15 18:50 ` Bart Schaefer @ 1997-01-16 9:37 ` Peter Stephenson 0 siblings, 0 replies; 3+ messages in thread From: Peter Stephenson @ 1997-01-16 9:37 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > On Jan 15, 10:37am, Peter Stephenson wrote: > } Subject: #! problem > } > } Somebody here tried something like: > } > } #!/bin/zsh -f > } # ^^^^empty spaces added here > > As opposed to ... full spaces? mmph. > 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). This sounds OK to me, and that's what I've written. There's one common case (common to me, anyway, I never realised it wasn't going to work) which isn't handled: #!/bin/zsh -f -*-ksh-*- (important if you don't like the new shell-mode in Emacs.) Looks like I'll have to get used to writing #!/bin/zsh -f-*-ksh-*- which also works as the second - terminates processing. I suppose everybody else knew that already. *** Doc/zsh.texi.opt Thu Jan 16 09:51:24 1997 --- Doc/zsh.texi Thu Jan 16 10:33:55 1997 *************** *** 5483,5488 **** --- 5483,5499 ---- the specification of option names by glob patterns, clashes with the use of @samp{-m} for setting the @code{MONITOR} option. + @noindent + Note also that whitespace at the end of an otherwise valid option + string is ignored. This is provided for the case when a zsh script is + invoked via a line of the form + + @code{#!/bin/zsh -@var{option-string}} + + @noindent + as many systems pass the text following the interpreter name with no + further processing. If any other text follows the whitespace an error + is signalled. @node Shell Builtin Commands, Programmable Completion, Options, Top @chapter Shell Builtin Commands *** Doc/zshoptions.man.opt Thu Jan 16 09:51:19 1997 --- Doc/zshoptions.man Thu Jan 16 10:33:01 1997 *************** *** 649,651 **** --- 649,663 ---- .BR unsetopt , allowing the specification of option names by glob patterns, clashes with the use of \-\fBm\fP for setting the MONITOR option. + .PP + Note also that whitespace at the end of an otherwise valid option + string is ignored. This is provided for the case when a zsh script is + invoked via a line of the form + .PP + .nf + #!/bin/zsh \-\fIoption_string\fP + .fi + .PP + as many systems pass the text following the interpreter name with no + further processing. If any other text follows the whitespace an error + is signalled. *** Src/init.c.opt Wed Jan 8 11:13:10 1997 --- Src/init.c Thu Jan 16 10:31:15 1997 *************** *** 205,210 **** --- 205,211 ---- /* loop through command line options (begins with "-" or "+") */ while (*argv && (**argv == '-' || **argv == '+')) { + char *args = *argv; action = (**argv == '-'); if(!argv[0][1]) *argv = "--"; *************** *** 237,242 **** --- 238,251 ---- zerr("no such option: %s", *argv, 0); 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@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1997-01-16 9:38 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-01-15 9:37 #! problem Peter Stephenson 1997-01-15 18:50 ` Bart Schaefer 1997-01-16 9:37 ` 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).