From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Peter Stephenson <pws@ifh.de>,
zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Re: #! problem
Date: Wed, 15 Jan 1997 10:50:34 -0800 [thread overview]
Message-ID: <970115105034.ZM14647@candle.brasslantern.com> (raw)
In-Reply-To: Peter Stephenson <pws@ifh.de> "#! problem" (Jan 15, 10:37am)
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
next prev parent reply other threads:[~1997-01-15 18:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-01-15 9:37 Peter Stephenson
1997-01-15 18:50 ` Bart Schaefer [this message]
1997-01-16 9:37 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=970115105034.ZM14647@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=pws@ifh.de \
--cc=schaefer@nbn.com \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).