Zsh Mailing List Archive
Messages sorted by:
Re: Change in FIGNORE behavior
- X-seq: zsh-workers 23524
- From: Peter Stephenson <pws@xxxxxxx>
- To: "zsh workers" <zsh-workers@xxxxxxxxxx>
- Subject: Re: Change in FIGNORE behavior
- Date: Tue, 05 Jun 2007 15:19:34 +0100
- In-reply-to: <070604095654.ZM17620@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20a807210705291856qe306eeds250f4f9d5f4dd33f@xxxxxxxxxxxxxx> <200705300945.l4U9jUbE009607@xxxxxxxxxxxxxx> <20070530112934.3950357b@xxxxxxxxxxxxxx> <070530035810.ZM29792@xxxxxxxxxxxxxxxxxxxxxx> <200705301127.l4UBROR5010814@xxxxxxxxxxxxxx> <20070530135436.410e11ff@xxxxxxxxxxxxxx> <20070604104901.276f7d83@xxxxxxxxxxxxxx> <070604095654.ZM17620@xxxxxxxxxxxxxxxxxxxxxx>
Bart Schaefer wrote:
> } I think the ideal case would be that a failed (R) returned an index off the
> } beginning of the array.
> That would be ideal for (I) as well, and in the absence of KSH_ARRAYS it
> would sort of be possible. Maybe what we need is (sigh) yet another flag
> that controls the behavior of index zero.
> Given such a flag (and possibly even without it), we could make it an
> error to assign to array (treat it as an invalid identifier) when the
> KSH_ARRAYS option is not in effect.
If that's possible, that would be great; I could back off the previous
patch. I was figuring it's such long-standing behaviour that that won't
work. However, it's not a feature you actually need, just one to stop
old shells falling over.
We could introduce an option KSH_INDEX_ZERO, or something. It turns out
the internal changes to support that aren't trivial, because the
parameter code is such a mess---it's built in a lot of layers which
aren't well separated from one another and depend on little details of
the layers underneath, and which furthermore are called from other parts
of the shell code at all the different levels, and the resulting mess
isn't documented: try to work out what the effect of changing the use of
the "start" and "end" elements of a "struct value" are. I've always
wanted much more hierarchical parameter code with well-defined APIs;
it's looking like one of those things that are never going to happen.
> When KSH_ARRAYS *is* in effect, you
> already have to jump through hoops to figure out what it means for (I)
> to return zero, so one is really no worse off in that case.
Yes, I agree entirely with that.
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
Messages sorted by: