From: TGAPE! <tgape@cyberramp.net>
To: schaefer@brasslantern.com (Bart Schaefer)
Cc: zsh-workers@math.gatech.edu
Subject: Re: Docs fix
Date: Mon, 26 Oct 1998 22:02:44 +0000 (GMT) [thread overview]
Message-ID: <199810262202.WAA06805@dal-tsa33-1.cyberramp.net> (raw)
In-Reply-To: <981026182717.ZM12068@candle.brasslantern.com> from "Bart Schaefer" at Oct 26, 98 06:27:17 pm
Bart Schaefer wrote:
>
> On Oct 26, 7:25pm, Zoltan Hidvegi wrote:
>> Subject: Re: Docs fix
>>> > The first one is just some stuff for the FAQ about $* vs "$@"
>>>
>>> The FAQ was correct without this patch. $* and "$@" are equivalent in
>>> zsh, unless you run it under Bourne sh or ksh emulation (i.e. with the
>>> SH_WORD_SPLIT option set).
>>
>> Not exactly. "$@" keeps empty arguments and independent of option and
>> IFS settings, neither of which is true for $*.
>
> Yes, but as I was just explaining privately to Phil, the context of his
> change is "what zsh construct is most like using \!* in csh aliases?"
>
> The best answer is $*, because you have to use \!*:q to get "$@" behavior
> in csh. An argument could be made that $==* is even better, but not "$@".
But, to quote Zoltan,
> It's good habbit to use "$@". The use of $* is almost always wrong
> in bourne/korn shell scripts still people use that all the time.
Who cares if it is the behavior that is most equivalent, when the
behavior is not what they want?!? I remember when I was stuck with
tcsh, back in the days before zsh became useful, I used to *dream* of
having "$@". When I found out ksh had it, I nearly switched, even
though I couldn't stand the static user interface. I did switch for all
my shell scripts.
Showing people how to mimic the broken behavior of their old shells is
not necessarily a good way to win converts or friends. However, I do
think the FAQ should be modified to mention that no, this isn't the the
exact same behavior, this is better.
Btw, can you show even *one* case where a csh user really wants $*
functionality and not "$@"? And, even if $* by default acted exactly
like "$@", it's a good idea to script so as to be complient with as many
shells as is reasonable. (That is, going lowest common denominator
bites big-time. However, when you have two equivalent ways of doing
something, and one is supported in two shells, and one only in zsh, do
the multiple shell one. When you get a job where you're politically
required to use ksh, you'll be glad you kept up with that practice.
Though, I have this annoying tendancy to start scripts with #!/bin/zsh.
Doesn't work very well...)
Ed the slightly annoyed
next prev parent reply other threads:[~1998-10-27 3:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-10-26 23:03 Phil Pennock
1998-10-26 23:53 ` Bart Schaefer
1998-10-27 1:25 ` Zoltan Hidvegi
1998-10-27 2:27 ` Bart Schaefer
1998-10-26 22:02 ` TGAPE! [this message]
1998-10-27 4:05 ` Phil Pennock
1998-10-27 4:21 ` Bart Schaefer
1998-10-27 5:13 ` Zoltan Hidvegi
1998-10-28 4:53 ` Bart Schaefer
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=199810262202.WAA06805@dal-tsa33-1.cyberramp.net \
--to=tgape@cyberramp.net \
--cc=schaefer@brasslantern.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).