Re: Docs fix

Re: Docs fix

[TGAPE!]

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

Docs fix

[Phil Pennock]

Quick docs fix; fairly trivial.

The first one is just some stuff for the FAQ about $* vs "$@"

The second one is a couple of fixes for grammar.yo -- a typo and a
semantic flaw.

They're both small, so in just one mail.  I think you can just stick two
diffs together the way I have ...

-Phil
-----------------------------< cut here >-------------------------------
*** Etc/FAQ.yo.old	Wed Apr 29 00:50:21 1998
--- Etc/FAQ.yo	Thu Oct 15 23:25:21 1998
***************
*** 687,698 ****
    )
    can be replaced by the zsh function,
    verb(
!     cd() { builtin cd $*; echo $PWD; }
    )
    (the `builtin' tells zsh to use its own `cd', avoiding an infinite loop)
    or, perhaps better,
    verb(
!     cd() { builtin cd $*; print -D $PWD; }
    )
    (which converts your home directory to a tt(~)).  In fact, this problem is
    better solved by defining the special function chpwd() (see the manual).
--- 687,698 ----
    )
    can be replaced by the zsh function,
    verb(
!     cd() { builtin cd "$@"; echo $PWD; }
    )
    (the `builtin' tells zsh to use its own `cd', avoiding an infinite loop)
    or, perhaps better,
    verb(
!     cd() { builtin cd "$@"; print -D $PWD; }
    )
    (which converts your home directory to a tt(~)).  In fact, this problem is
    better solved by defining the special function chpwd() (see the manual).
***************
*** 704,719 ****
    SETCOUNTER(XXenumcounter)(0)
    enumerate(
    myeit() If the csh alias references "parameters" (tt(\!:1), tt(\!*) etc.),
!      then in zsh you need a function (referencing tt($1), tt($*) etc.).
       Otherwise, you can use a zsh alias.
  
    myeit() If you use a zsh function, you need to refer _at_least_ to
!      tt($*) in the body (inside the tt({ })).  Parameters don't magically
       appear inside the tt({ }) the way they get appended to an alias.
  
    myeit() If the csh alias references its own name (tt(alias rm "rm -i")),
       then in a zsh function you need the "command" keyword
!      (function tt(rm() { command rm -i $* })), but in a zsh alias
       you don't (tt(alias rm="rm -i")).
  
    myeit() If you have aliases that refer to each other (tt(alias ls "ls -C";
--- 704,719 ----
    SETCOUNTER(XXenumcounter)(0)
    enumerate(
    myeit() If the csh alias references "parameters" (tt(\!:1), tt(\!*) etc.),
!      then in zsh you need a function (referencing tt($1), tt($*) or tt("$@") etc.).
       Otherwise, you can use a zsh alias.
  
    myeit() If you use a zsh function, you need to refer _at_least_ to
!      tt($*) or tt("$@") in the body (inside the tt({ })).  Parameters don't magically
       appear inside the tt({ }) the way they get appended to an alias.
  
    myeit() If the csh alias references its own name (tt(alias rm "rm -i")),
       then in a zsh function you need the "command" keyword
!      (function tt(rm() { command rm -i "$@" })), but in a zsh alias
       you don't (tt(alias rm="rm -i")).
  
    myeit() If you have aliases that refer to each other (tt(alias ls "ls -C";
***************
*** 766,772 ****
    There is one other serious problem with aliases: consider
    verb(
      alias l='/bin/ls -F'
!     l() { /bin/ls -la $* | more }
    )
    mytt(l) in the function definition is in command position and is expanded
    as an alias, defining mytt(/bin/ls) and mytt(-F) as functions which call
--- 766,772 ----
    There is one other serious problem with aliases: consider
    verb(
      alias l='/bin/ls -F'
!     l() { /bin/ls -la "$@" | more }
    )
    mytt(l) in the function definition is in command position and is expanded
    as an alias, defining mytt(/bin/ls) and mytt(-F) as functions which call
*** Doc/Zsh/grammar.yo.old	Thu Oct 15 23:28:26 1998
--- Doc/Zsh/grammar.yo	Thu Oct 15 23:35:11 1998
***************
*** 117,123 ****
  cindex(for loops)
  cindex(loops, for)
  item(tt(for) var(name) [ tt(in) var(word) ... var(term) ] tt(do) var(list) tt(done))(
! where var(term) is one ore more newline or tt(;).
  Expand the list of var(word)s, and set the parameter
  var(name) to each of them in turn, executing
  var(list) each time.  If the tt(in) var(word) is omitted,
--- 117,123 ----
  cindex(for loops)
  cindex(loops, for)
  item(tt(for) var(name) [ tt(in) var(word) ... var(term) ] tt(do) var(list) tt(done))(
! where var(term) is one or more newline or tt(;).
  Expand the list of var(word)s, and set the parameter
  var(name) to each of them in turn, executing
  var(list) each time.  If the tt(in) var(word) is omitted,
***************
*** 211,217 ****
  cindex(testing conditional expression)
  item(tt([[) var(exp) tt(]]))(
  Evaluates the conditional expression var(exp)
! and return a zero exit status if it is true.
  See noderef(Conditional Expressions)
  for a description of var(exp).
  )
--- 211,217 ----
  cindex(testing conditional expression)
  item(tt([[) var(exp) tt(]]))(
  Evaluates the conditional expression var(exp)
! and return a zero exit status iff it is true.
  See noderef(Conditional Expressions)
  for a description of var(exp).
  )

Re: Docs fix

[Bart Schaefer]

On Oct 26, 11:03pm, Phil Pennock wrote:
> Subject: Docs fix
> Quick docs fix; fairly trivial.

Thanks for the suggestions, but ...

> 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).

> The second one is a couple of fixes for grammar.yo -- a typo and a
> semantic flaw.

The typo fix appeared in one of my doc patches ... zsh-workers/4118 is
the article ... along with some other clarifications of the surrounding
text.

The semantic flaw is arguable, but in patches of this type please spell
out phrases like "if and only if" rather than using abbreviations with
which some readers of zsh documentation may be unfamiliar.

Re: Docs fix

[Zoltan Hidvegi]

> > 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 $*.  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.

Zoli

Re: Docs fix

[Bart Schaefer]

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 "$@".

Re: Docs fix

[Phil Pennock]

Typing away merrily, TGAPE! produced the immortal words:
> 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

Sure.  A wrapper around an su command, for instance, which takes a
single argument for -c ... or anything else where a command wants a
shell sequence as one arg, but your csh-alias/*sh-func should just stick
all args after the nth into that.  I'm fairly sure I have something like
that knocking around somewhere.
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* !r y?

Re: Docs fix

[Bart Schaefer]

On Oct 26, 10:02pm, TGAPE! wrote:
> Subject: Re: Docs fix
> > 
> >> 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 "$@".
> 
> Who cares if it is the behavior that is most equivalent, when the
> behavior is not what they want?!?

The context here is the question about converting csh aliases to zsh.

Csh aliases DO HAVE the equivalent of the "$@" construct.  It's \!*:q.

If one has a CORRECTLY WORKING ALIAS that uses \!* without the :q, then
using "$@" in the replacement zsh function will *NOT* do what one wants,
in at least some circumstances.

In ANY OTHER CONTEXT, *especially* in shells scripts, everything that is
being said about "$@" being better is *absolutely* correct.  But it is
NOT correct in the FAQ question where Phil's patch changes it!

> 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.

A zsh function intended to replace a csh alias is not a bourne/korn script.
Otherwise I completely agree.

> 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.

Sigh.  Look.  The FAQ cannot possibly explain all circumstances in which
"$@" is correct.  When it's correct, it's better; when it's wrong, it's
not better.

> Btw, can you show even *one* case where a csh user really wants $*
> functionality and not "$@"?

Sure.  Warning, csh syntax follows.

alias   do      "\!* >&! did &"
alias   dopr    '\!* | lpr -J "\!:1"'

If you replace $* with "$@" when converting those aliases, you end up
quoting the word in the command position, which causes unexptected side
effects.

> 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.

This is all wonderful advice, but completely out of context for the place
that Phil's patch made the change.

Re: Docs fix

[Zoltan Hidvegi]

Wow, I did not expect to stir such a debate.

> The context here is the question about converting csh aliases to zsh.

Sure, and you are absolutely right in that \!* corresponds to $*.  And
there are certainly legitime cases where you would realy want to use $*.
But the examples in the FAQ are not such cases:

    cd() { builtin cd $*; echo $PWD; }
    rm() { command rm -i $* }
    l() { /bin/ls -la $* | more }

In all these cases you really want to use "$@".  Especially in case of
cd, I often use the two argument cd with empty second argument.  There is
a good example in the FAQ where $* is the right thing:

    xhead () { print -n "\033]2;$*\a"; }

And one more point, people misuse csh's \!* as often as they do misuse
$*.

> alias   do      "\!* >&! did &"
> alias   dopr    '\!* | lpr -J "\!:1"'
> 
> If you replace $* with "$@" when converting those aliases, you end up
> quoting the word in the command position, which causes unexptected side
> effects.

This really does not have any relevance to this discussion, but what are
those side effects?  Alias expansion and reserved word recognition is not
done on the result of either $* or "$@" expansion.  The exact conversion
of these csh aliases would be rather tricky.

Zoli

Re: Docs fix

[Bart Schaefer]

On Oct 26, 11:13pm, Zoltan Hidvegi wrote:
} Subject: Re: Docs fix
}
} > If you replace $* with "$@" when converting those aliases, you end up
} > quoting the word in the command position, which causes unexptected side
} > effects.
} 
} This really does not have any relevance to this discussion, but what are
} those side effects?

Hm; well, you're right, I can no longer find any.  I'm pretty sure there
were at one time, but I could be remembering something from zsh 2.0.0 or
before, which is when I was actively converting things from csh.

I'm still of the opinion that a FAQ about zsh is better off sticking with
standard zsh syntax rather than attempt to present every example as usable
in every other similar shell -- because for one thing its impossible to do
it in every case, and for another I'd rather the FAQ were espousing the
things that zsh does better rather than advocating avoiding them because
they're unique -- but Peter's the FAQ maintainer and I won't argue with
whatever decision he makes on the issue.

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