Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Something like noglob to inhibit brace expansion?
- X-seq: zsh-users 6654
- From: Lloyd Zusman <ljz@xxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: Something like noglob to inhibit brace expansion?
- Date: Mon, 06 Oct 2003 13:19:40 -0400
- In-reply-to: <1031006170134.ZM4707@xxxxxxxxxxxxxxxxxxxxxxx> (Bart Schaefer's message of "Mon, 6 Oct 2003 17:01:34 +0000")
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <m3wubkmv0y.fsf@xxxxxxxxxx> <1031005162121.ZM2735@xxxxxxxxxxxxxxxxxxxxxxx> <m3y8vy8nfr.fsf@xxxxxxxxxx> <1031006170134.ZM4707@xxxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: ljz@xxxxxxxxxx
- Sender: Lloyd Zusman <ljz@xxxxxxxxxx>
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> writes:
> On Oct 6, 10:12am, Lloyd Zusman wrote:
> }
> } Hmm ... or what about this as an even uglier alternative (one long
> } line in real life)?
> }
> } alias pr='eval "preexec() { setopt braceexpand; preexec(){} }" &&
> } setopt ignorebraces && noglob print'
>
> No, this won't work -- preexec is executed once before each interactive
> command _line_ is executed, not before every individual command in any
> pipeline or list. So in that example, preexec won't be defined until
> after it would have executed. It'll execute before the _next_ command,
> but by that time it's too late -- parsing of that next command is over,
> and won't have used braceexpand.
That's the idea. I want it to execute before the _next_ command (in
other words, _after_ the specified command executes), because it turns
braceexpand back _on_ after it was turned off for that one, single
command.
> You could do it with precmd instead of preexec.
>
> } There's even probably some sort of way to make a generic alias or
> } function for this, which can then be applied to any command
>
> [ ... etc. ... ]
Thank you. I'm going to play with this. Fun!
> [ ... ]
>
> } Feature suggestion: how about adding [...] an 'ignore' precommand
> } modifier which takes options that can be grouped together, such as -b
> } for braces, -g for glob, -v for variable expansion, etc.?
>
> That's an interesting idea, though it may be very difficult to manage
> it for those expansions that don't already have options. Expansions
> introduced with '$' in particular are tied to parsing at several levels,
> because the presence of '${' or '$(' changes the parse of everything
> that follows, up to the matching '}' or ')'.
>
> [ ... ]
I understand your cogent explanation. So maybe we could just have a
precommand modifier called 'raw' or something similar, which just passes
in the command line with no expansions whatsoever. The program or
function could do its own parsing in that case.
Hmm ... isn't one of the three arguments passed to preexec already the
raw, unexpanded command? If so, is there a way to use preexec to modify
the command line that is about to be executed?
--
Lloyd Zusman
ljz@xxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author