zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-users@zsh.org
Subject: Re: When it is allowed to use alias after defining it?
Date: Fri, 30 Dec 2022 22:01:28 +0000	[thread overview]
Message-ID: <2f8d30f569ab6eae90a8ea1bda689907ecb49495.camel@ntlworld.com> (raw)
In-Reply-To: <CAKc7PVDiE_sbhV3XfDFQAg1qGNe1JJJ6rP1fS5BSxxzPnabMVw@mail.gmail.com>

On Fri, 2022-12-30 at 21:45 +0000, Sebastian Gniazdowski wrote:
> I was thinking that in current file it is impossible to use an alias – only should work in sourced sub-script. 
> 
> So:
> alias q=pushd
> # Expected to not work
> q
> # Expected to work
> source ./using-q.zsh
> 
> The script is fine to use q. Is that the truth? Because I'm using
> aliases in the same file, only if it is at some proximity from
> definition. What are the rules here?

It's a question of when the execution of the line happens in relation to
parsing it, and also of the fact that expanding an alias happens very
early at the point where the line is read in.

When reading a script, the shell reads one line at a time --- if the
line contains an unfinished complex command, it will continue reading
until that's finished.  Then it executes it, before reading anything
else, so if the line was an alias definition that's available from then
on.  That's pretty much the same as what happens in an interactive
shell, in fact it's the same internal logic --- the difference between
the two occurs at the point where the shell gets input, where it decides
whether it's blindly going to read a line or invoke the editor.

So complex commands are the key case where the effect is delayed.  This
obviously includes functions; the classic case where you *can't* rely on
an alias being defined is:

fn() {
  alias q=pusehd
  q
}

since the function is defined in one go before the alias is defined
within the function.  Because aliases are resolved on input, the q is
treated as a normal command within the function.

Although this is a logical consequence of shell input, it's certainly
not an obvious one.

pws



      reply	other threads:[~2022-12-30 22:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 21:45 Sebastian Gniazdowski
2022-12-30 22:01 ` 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=2f8d30f569ab6eae90a8ea1bda689907ecb49495.camel@ntlworld.com \
    --to=p.w.stephenson@ntlworld.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).