From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-users@zsh.org
Subject: Re: make aliases work inside the function? (using a preprocessor?)
Date: Wed, 04 May 2016 15:04:22 +0100 [thread overview]
Message-ID: <20160504150422.7afa6805@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <20160504134632.GA5729@aurora-borealis.phear.org>
On Wed, 4 May 2016 13:46:32 +0000
Marc Chantreux <khatar@phear.org> wrote:
> sometimes i really need aliases.
> sometimes aliases seems to work inside functions.
>
> sometimes it works, sometimes it doesn't.
The probably is likely to be order dependence. If you've defined an
alias, it's then available for expansion at the start of the command
line *even* if that word is defining a function.
This is explained in the FAQ (2.3; this is a long entry,
unsurprisingly).
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.
next prev parent reply other threads:[~2016-05-04 14:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 13:46 Marc Chantreux
2016-05-04 14:04 ` Peter Stephenson [this message]
2016-05-04 14:55 ` Oliver Kiddle
2016-05-04 17:21 ` Bart Schaefer
2016-05-09 12:30 ` Marc Chantreux
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=20160504150422.7afa6805@pwslap01u.europe.root.pri \
--to=p.stephenson@samsung.com \
--cc=zsh-users@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).