From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: activate alias inside subshell
Date: Sun, 8 Apr 2018 07:56:08 -0700 [thread overview]
Message-ID: <c046e21b-ea69-a757-269f-f8493ae47912@eastlink.ca> (raw)
In-Reply-To: <CAH+w=7b53+0hWyVoLw5CzRZPpGjE_8b9jKVbDETbE6awehA2ww@mail.gmail.com>
On 08/04/18 12:39 AM, Bart Schaefer wrote:
> I'm not going to try to respond blow-by-blow to your messages, because
> there still seem to be some concepts about aliasing that we've
> discussed in past threads that you don't appear to be applying.
It does take a while for some things to stick, but they do stick
eventually. There are so many things assumed to be understood in the
culture. Misunderstood, answers don't really gel, the mind hunts for a
'get it' but the 'get it' is false. Like only recently do I finally
really get it as to bleeding newlines in arrays -- not there!
> Firstly, though, there's something that doesn't add up about your
> "test1" example; as you quoted it, "yelline" references a variable
> $yel that's never assigned,
Pardon, I try to copy in all the relevant bits and pieces from my
environment. That's just the code for 'yellow' of course. What's the
best way to run something as a test for fitness to export it, as to
here, for example? I mean a way of ensuring that it's entirely
self-contained as to things like that and nothing has been left out or
assumed?
> I suspect you're using a shell in which you've been running other
> tests and something from an earlier experiment is spilling over to
> confuse you. Either that, or you haven't actually shown us the full
> contents of the "test1" file.
Sure. As above, I'm always worried that there's some local setting or
glitch that makes my code invalid as far as other people pasting it from
an email and getting the same results. I need a sort of 'virgin' test
before sending these things on. Should have got that squared away years
ago.
> The fundamental thing you're forgetting is that aliases act by text
> replacement. "whence" will tell you whether an alias WILL replace
> text the NEXT time the lexer is invoked, but that has no meaning for
> text that has previously been parsed. Function definitions are always
> fully lexed+parsed before they are executed, so once a function is
> defined any aliases it may have used have been replaced by the
> expanded text of the alias and can never expand again.
Ok, so whence is simply obeying the 'not active till next time' rule.
Not very friendly but it is consistent with the law of aliases.
> % alias msg='echo this is an alias'
> % test1() { msg in test1 }
> % functions test1
> test1 () {
> echo this is an alias in test1
> }
> %
>
> See how the use of the alias is no longer present in the stored
> definition of test1?
That at least is exactly as I expect, it's a macro.
> Note that it's important that the alias and the
> function were defined separately (in this example at separate PS1
> prompts), so that the parser was run a second time AFTER the alias was
> defined.
>
> Compare running the parser only once, by using a multi-line construct
> (I have started a fresh "zsh -f" for each of these examples even
> though I've changed the function names to differentiate them):
Is 'zsh -f' the answer to the above -- a truly clean test of something?
> Here test2 was parsed at the same time as the alias command, so the
> alias was not yet "active" when the body of test2 was read, and thus
> the alias definition is both not expanded in test2 and also irrelevant
> at the time the function is executed.
So:
$ alias msg ... ; test2 () { msg }
and:
$ alias msg ...
$ test2 () { msg }
... are very different! In the former the alias is 'pending' in the
latter, it is active, yes? That's easy not to know.
> Something like this must be involved in producing the "nulled" output
> from the example you posted.
Ok, let me hack away at it a bit more. Nevermind whence, the only
serious issue is the way the redefined function seems to kill the alias
within the subshell within the calling function. Again, it turns out
that this is exactly what I want, but not something I understand. It is
as if the fact that the redefined function has the same name as the
alias overwrites the namespace within the subshell so the alias
vanishes. If so, that could be seen as a feature not a bug.
BTW, results are hugely different if the redefined message function is
redefined with or without 'function' prepended: " function msg () ... "
vs. " msg () ... ". Most comments found on the internet suggest there
should be no difference but that is not so, one changes things
externally, the other does not. It added to the confusion.
next prev parent reply other threads:[~2018-04-08 14:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 16:29 Ray Andrews
2018-04-07 19:57 ` Ray Andrews
2018-04-08 7:39 ` Bart Schaefer
2018-04-08 14:56 ` Ray Andrews [this message]
2018-04-08 20:18 ` Bart Schaefer
2018-04-08 20:54 ` Ray Andrews
2018-04-08 22:38 ` Ray Andrews
2018-04-09 4:11 ` Ray Andrews
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=c046e21b-ea69-a757-269f-f8493ae47912@eastlink.ca \
--to=rayandrews@eastlink.ca \
--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).