zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: Bug in alias expansion
Date: Tue, 17 Nov 2015 20:55:08 -0800	[thread overview]
Message-ID: <151117205508.ZM26027@torch.brasslantern.com> (raw)
In-Reply-To: <20151117172951.01bf1825@pwslap01u.europe.root.pri>

On Nov 17,  5:29pm, Peter Stephenson wrote:
}
} We can get rid of the currently visible problems by allocating a new
} string for the token and copying back the result to the original.

A few remarks about this.

(1) This doesn't resolve the problem I pointed out in workers/37123.

(2) Referring to the discussion I've been having with Mikael (cf.
    workers/37126), with this patch the alias is expanded in the
    parent shell for "alias -g" and in the subshell without -g.
    When the $(...) expansion is NOT in subscript context, on the
    other hand, the alias expands in the subshell for both global
    and command aliases.

(3) I'm fibbing in the last sentence of (2).  The alias is expanded
    BOTH in the parent shell (which is where the "fooecho" bug from
    37123 arises) AND in the subshell.  In the parent shell the alias
    is expanded during the parse but then (in the case where it lexes
    correctly) the expansion is thrown away, only to be re-expanded
    in the subshell.

Consequently ... either Mikael is right that the alias expansion
should be forced into the subshell, your patch is thus "wrong," and
my patch in 37122 is closer to what should happen; or the parent is
responsible for the alias, and when we fix 37123 we should make the
behavior outside of subscripts consistent with the behavior inside.

(Of course 37128 and 37122 aren't mutually exclusive, we can apply
both; there's probably some other case where subscript parsing may
go wrong that's fixed by 37128.)

} It's not very efficient, and it still has the problem that if something
} funny happens to the length --- and I don't think there's any guarantee
} of length preservation built into the lexer even though it happens to
} work in the cases we've looked at so far --- then somebody's going to
} get hurt.

I'm not following this stuff about the length -- it can't mean that the
length of the alias expansion is the same as the length of the aliased
token -- so to what does it refer?


  reply	other threads:[~2015-11-18  4:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 18:03 Kynn Jones
2015-11-14  1:03 ` Bart Schaefer
2015-11-14 18:57   ` Kynn Jones
2015-11-14 19:03     ` Bart Schaefer
2015-11-14 19:19       ` Kynn Jones
2015-11-14 21:40         ` Bart Schaefer
2015-11-14 22:20           ` Kynn Jones
2015-11-15 20:03 ` Peter Stephenson
2015-11-15 21:52   ` Bart Schaefer
2015-11-15 22:26     ` Bart Schaefer
2015-11-15 22:48   ` Bart Schaefer
2015-11-16  0:50     ` Mikael Magnusson
2015-11-16  3:24       ` Bart Schaefer
2015-11-16  5:42         ` Mikael Magnusson
2015-11-18 10:42     ` Peter Stephenson
2015-11-18 14:13       ` Peter Stephenson
2015-11-18 15:52         ` Bart Schaefer
2015-11-18 16:14           ` Peter Stephenson
2015-11-18 18:09             ` Bart Schaefer
2015-11-17 17:29   ` Peter Stephenson
2015-11-18  4:55     ` Bart Schaefer [this message]
2015-11-18 10:30       ` Peter Stephenson

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=151117205508.ZM26027@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).