zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: <zsh-workers@zsh.org>
Subject: Re: zsh function declaration bug
Date: Thu, 31 Jan 2019 14:00:08 +0000	[thread overview]
Message-ID: <1548943208.4543.1.camel@samsung.com> (raw)
In-Reply-To: <730BA7F6-5BE4-419D-838E-457B43F93B90@dana.is>

On Thu, 2019-01-31 at 07:11 -0600, dana wrote:
> On 30 Jan 2019, at 11:46, Mitchell Gildenberg <mgild@google.com> wrote:
> >
> > ➜ mgild $ l(){ echo "hello"}
> > zsh: defining function based on alias `ls'
> > zsh: parse error near `()'
> Presumably you have an alias l=ls, which is being expanded because the l in
> l() { ... } is considered to be in command position. workers/40300 made this
> an error by default, since the expansion behaviour is generally unexpected
>
> If you don't need the l alias, you can just unalias it. Otherwise it will
> work with the function key word like you said, or if you put the definition in
> a file rather than entering it at the command line. But i'm guessing you don't
> actually want an alias and a function with the same name anyway

Yes, this is described in the FAQ, quoted at the bottom (it lives in the
source distribution in the Etc directory, or at
http://zsh.sourceforge.net/FAQ/).  This was written before you got the
error message when this happened.

The new error is basically there to tell you "you don't want to do
this".  The old behaviour --- silently defining functions based on
aliases --- was almost never what you wanted.

pws


There is one other serious problem with aliases: consider

    alias l='/bin/ls -F'
    l() { /bin/ls -la "$@" | more }

  `l' in the function definition is in command position and is expanded
  as an alias, defining `/bin/ls' and `-F' as functions which call
  `/bin/ls', which gets a bit recursive.  This can be avoided if you use
  `function' to define a function, which doesn't expand aliases.  It is
  possible to argue for extra warnings somewhere in this mess.

One workaround for this is to use the "function" keyword instead:

    alias l='/bin/ls -F'
    function l { /bin/ls -la "$@" | more }

  The `l' after `function' is not expanded.  Note you don't need
  the `()' in this case, although it's harmless.

You need to be careful if you are defining a function with multiple
  names; most people don't need to do this, so it's an unusual problem,
  but in case you do you should be aware that in versions of the shell
  before 5.1 names after the first were expanded:

    function a b c { ... }

  Here, `b' and `c', but not `a', have aliases expanded.
  This oddity was fixed in version 5.1.

The rest of this item assumes you use the (more common,
  but equivalent) `()' definitions.

Bart Schaefer's rule is:  Define first those aliases you expect to
  use in the body of a function, but define the function first if the
  alias has the same name as the function.

If you aware of the problem, you can always escape part or all of the
  name of the function:

     'l'() { /bin/ls -la "$@" | more }

  Adding the quotes has no effect on the function definition, but
  suppresses alias expansion for the function name.  Hence this is
  guaranteed to be safe---unless you are in the habit of defining
  aliases for expressions such as 'l', which is valid, but probably
  confusing.



      reply	other threads:[~2019-01-31 14:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 17:46 Mitchell Gildenberg
2019-01-31 13:11 ` dana
2019-01-31 14:00   ` Peter Stephenson [this message]

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=1548943208.4543.1.camel@samsung.com \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /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).