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