zsh-workers
 help / color / mirror / code / Atom feed
From: Zoltan Hidvegi <hzoli@frontiernet.net>
To: schaefer@brasslantern.com (Bart Schaefer)
Cc: zsh-workers@math.gatech.edu (Zsh hacking and development)
Subject: Re: RC_EXPAND_PARAM bug
Date: Wed, 30 Jul 1997 02:51:35 -0400 (EDT)	[thread overview]
Message-ID: <199707300651.CAA01564@hzoli.home> (raw)
In-Reply-To: <970729231110.ZM19573@candle.brasslantern.com> from Bart Schaefer at "Jul 29, 97 11:11:10 pm"

> } 1. `a' was an empty array.  In that case the expansion is the empty list,
> }    and suffix is not evaluated (so even if there is a $[i++] in suffix, i
> }    will not change).
> 
> Hrm.  I think I would have expected to get prefixsuffix, with suffix
> evaluated.  That's what you get when a=("") or a="", but I can't decide
> if that represents an argument in favor, or against.

No, an empty array is very different from an array with a single empty
element.  For example a is a list of directories, and you wand a list of
files in there directories, you would say

$^a/*

If `a' is empty, you want $^a/* expand to nothing, otherwise you would
get the list of files in the root directory which you do not want.  Such
tricks are used in several zsh scripts I guess, and this is the
preferable behaviour.  And it always worked this way, that's the point
where there is not difference between versions.

> } and everything is evaluated once unless there is an rc-expansion of
> } an empty array which discards everything following that array.
> 
> It's that one that gives me pause.

One might require the evaluation of the suffix even if it is discarded
later.  Do you think it is preferable?

> } What would be the preferred evaluation of ${^a}1${^^x}?
> 
> What does the real "rc" shell do?  Duplicating it would be my first choice,
> unless it does something wildly different than any previous version of zsh.

I do not think this has anything to do with rc.  I always thought that rc
somehow comes from brace, since this kind of array expansion resembles
brace expansion.

> } Alternatives:
> } 
> } 1. a1x ay b1x by  (current)
> } 
> } 2. a1x y b1x y    (beta16 and older)
> } 
> } 3. a1x b1x y      (just an other logical solution).
> 
> The important question for me is, where are the word breaks in (2)?
> That is, if I do:
> 
>   z=(${^a}1${^^x})
> 
> What is ${#z}?  If z is ("a1x y" "b1x y"), then I think that's wrong.

It is 4.

> On Jul 30,  9:46am, Andrej Borsenkow wrote:
> } Subject: Re: RC_EXPAND_PARAM bug
> }
> } zsh-3.1.2 with RC_EXPAND_PARAM bugfix.
> } 
> } % echo ${^a}1${^^x}
> } a1x ay b1x by
> } 
> } % echo ${^^a}1${^x}
> } a b1x b1y
> } 
> } It looks illogical. Either the latter should be 'ax b1x ay b1y' or the
> } former 'a1x b1x y'. 
> 
> I agree with Andrej on that.  If you're going to map over lists, you
> have to map over them in the prefix too, not just in the suffix.
> 
> However, I don't like the behavior of (3), i.e. that when ${x} is a list
> then the word break interrupts the rc-expansion.  I'd prefer that the
> expansion proceed across the suffix in the same way regardless of whether
> x is an array or a string, and then introduce the word breaks at the end.

I do not understand exatly what you mean, but I'm leaning towards option
3.  One possible implementation is to prepend some otherwise impossible
string to suffix before expanding it, and after the expansion, check for
that, and replace it with elements of a.  The impossible string can be {
Meta, '@' } or a new metacharacter.  This seems to be a really simple to
do.  Option 2. can use the same trick, but if the modified ${^^a}1${^x}
behaviour you suggest above is also required, things become more
complicated.

Zoltan


  reply	other threads:[~1997-07-30  7:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-28 13:42 Andrew Main
1997-07-28 16:26 ` Bart Schaefer
1997-07-29  6:04   ` Zoltan Hidvegi
1997-07-29  7:09     ` Bart Schaefer
1997-07-29  7:36       ` Zoltan Hidvegi
1997-07-29  7:47     ` Geoff Wing
1997-07-29 16:27       ` Bart Schaefer
1997-07-30  3:04         ` Geoff Wing
1997-07-30  3:56           ` Bart Schaefer
1997-07-30  5:16         ` Zoltan Hidvegi
1997-07-30  5:46           ` Andrej Borsenkow
1997-07-30  6:11           ` Bart Schaefer
1997-07-30  6:51             ` Zoltan Hidvegi [this message]
1997-07-30  7:33               ` Bart Schaefer
1997-07-30  8:18           ` Andrew Main
1997-07-30 15:54             ` Andrej Borsenkow
1997-07-30 17:05               ` Bart Schaefer
1997-08-01 13:17                 ` Andrej Borsenkow
1997-08-01 18:18                   ` Bart Schaefer

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=199707300651.CAA01564@hzoli.home \
    --to=hzoli@frontiernet.net \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@math.gatech.edu \
    /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).