zsh-users
 help / color / mirror / code / Atom feed
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.



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