Change in FIGNORE behavior

Change in FIGNORE behavior

[Vin Shelton]

Greetings -

In a shell built from current CVS sources, I observe the following behavior:

vshelton-pc2% ls
svn-commit.tmp~
vshelton-pc2% ls <TAB> --> svn-commit.tmp~
vshelton-pc2% FIGNORE='~'
vshelton-pc2% autoload -U compinit
vshelton-pc2% compinit -u
vshelton-pc2% ls <TAB> --> BEEP

Even though FIGNORE is set, if there are no other matches, completion
should match the backup file, right?  That's the way the shell used to
behave.  I've done a little bisecting and it appears this behavior
changed sometime between 2007-05-15 and 007-05-23.

Was the change intentional?  If so, I don't particularly like it.  Can
we have the old behavior back?

Regards,
  Vin

-- 
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506

Re: Change in FIGNORE behavior

[Peter Stephenson]

"Vin Shelton" wrote:
> Greetings -
> 
> In a shell built from current CVS sources, I observe the following behavior:
> 
> vshelton-pc2% ls
> svn-commit.tmp~
> vshelton-pc2% ls <TAB> --> svn-commit.tmp~
> vshelton-pc2% FIGNORE='~'
> vshelton-pc2% autoload -U compinit
> vshelton-pc2% compinit -u
> vshelton-pc2% ls <TAB> --> BEEP
> 
> Even though FIGNORE is set, if there are no other matches, completion
> should match the backup file, right?  That's the way the shell used to
> behave.  I've done a little bisecting and it appears this behavior
> changed sometime between 2007-05-15 and 007-05-23.
> 
> Was the change intentional?  If so, I don't particularly like it.  Can
> we have the old behavior back?

I certainly don't think it was intentional and I can't offhand see any
patch what ought to change it.  Also, it doesn't seem to be happening
for me.  This is supposed to be handled by the _ignored completer;
is some change causing that not to be set?  If not, maybe the output of
_complete_debug would be helpful.

-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Peter Stephenson]

On Wed, 30 May 2007 10:45:29 +0100
Peter Stephenson <pws@csr.com> wrote:
> > Even though FIGNORE is set, if there are no other matches,
> > completion should match the backup file, right?  That's the way the
> > shell used to behave.  I've done a little bisecting and it appears
> > this behavior changed sometime between 2007-05-15 and 007-05-23.
> 
> This is supposed to be handled by the _ignored completer;
> is some change causing that not to be set?  If not, maybe the output
> of _complete_debug would be helpful.

I've found what's causing it by using the default set of completers: it's
the effect of the change in (R) on this code in _ignored:

  zstyle -a ":completion:${curcontext}:" completer comp ||
    comp=( "${(@)_completers[1,_completer_num-1][(R)_ignored(|:*),-1]}" )

With

  _completers=(_complete _ignored)
  _completer_num=2

comp used to get set to _complete, now its empty.  It previously worked
because a failure to find _ignored(|:*) set the second start subscript to 0
which was interpreted as 1.  I presume the idea is we only want completers
starting from any previous occurence of _ignored, or the start.  This is a
bit too opaque for my liking anyway.  This expands that form where it
occurs in both _ignored and _prefix.

I'm glad somebody spotted this.

Index: Completion/Base/Completer/_ignored
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_ignored,v
retrieving revision 1.1
diff -u -r1.1 _ignored
--- Completion/Base/Completer/_ignored	2 Apr 2001 11:07:28 -0000	1.1
+++ Completion/Base/Completer/_ignored	30 May 2007 10:25:26 -0000
@@ -5,9 +5,13 @@
 [[ _matcher_num -gt 1 || $compstate[ignored] -eq 0 ]] && return 1
 
 local comp
+integer ind
 
-zstyle -a ":completion:${curcontext}:" completer comp ||
-  comp=( "${(@)_completers[1,_completer_num-1][(R)_ignored(|:*),-1]}" )
+if ! zstyle -a ":completion:${curcontext}:" completer comp; then
+  comp=( "${(@)_completers[1,_completer_num-1]}" )
+  ind=${comp[(I)_ignored(|:*)]}
+  (( ind )) && comp=("${(@)comp[ind,-1]}")
+fi
 
 local _comp_no_ignore=yes tmp expl \
       _completer _completer_num \
Index: Completion/Base/Completer/_prefix
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_prefix,v
retrieving revision 1.4
diff -u -r1.4 _prefix
--- Completion/Base/Completer/_prefix	5 Dec 2003 10:35:24 -0000	1.4
+++ Completion/Base/Completer/_prefix	30 May 2007 10:25:26 -0000
@@ -7,9 +7,13 @@
 local comp curcontext="$curcontext" tmp suf="$SUFFIX" \
       _completer \
       _matcher _c_matcher _matchers _matcher_num
+integer ind
 
-zstyle -a ":completion:${curcontext}:" completer comp ||
-  comp=( "${(@)_completers[1,_completer_num-1][(R)_prefix(|:*),-1]}" )
+if ! zstyle -a ":completion:${curcontext}:" completer comp; then
+  comp=( "${(@)_completers[1,_completer_num-1]}" )
+  ind=${comp[(I)_prefix(|:*)]}
+  (( ind )) && comp=("${(@)comp[ind,-1]}")
+fi
 
 if zstyle -t ":completion:${curcontext}:" add-space; then
   ISUFFIX=" $SUFFIX"


-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Bart Schaefer]

On May 30, 11:29am, Peter Stephenson wrote:
}
} I've found what's causing it by using the default set of completers: it's
} the effect of the change in (R) on this code in _ignored:
} 
}   zstyle -a ":completion:${curcontext}:" completer comp ||
}     comp=( "${(@)_completers[1,_completer_num-1][(R)_ignored(|:*),-1]}" )

I knew something was nagging me about that change to (R).  Here's
another thing that I just remembered:

var[(R)pattern] is an assignable construct.  Previously

var[(R)missing]=something

would replace the first element.  Now it appends an element to the end.
You might think this is inconsequential until you remember that

var[(R)missing]=( a whole lot of something )

will now append the entire new array, whereas before it spliced the
new elements into the front of the old array.

That's going to bite somebody ... in fact I appear to have a script
that relies on the old behavior, although it's one I haven't used in
a long time.

Re: Change in FIGNORE behavior

[Peter Stephenson]

Bart Schaefer wrote:
> var[(R)pattern] is an assignable construct.  Previously
> 
> var[(R)missing]=something
> 
> would replace the first element.  Now it appends an element to the end.

Hmmm... (R) was documented to refer to the last match found, so anyone
relying on it replacing something at the beginning (or, indeed, doing
anything well-defined at all) on a failure is making unwarranted
assumptions.  Still, if this is going to cause multiple hard to find
problems it's going to be a continuing nuisance.

It would be nice to be able to detect if the index is going to be used
for something other than extracting a single element and use the first
index if so, but the current interface doesn't make that easy.

-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Peter Stephenson]

On Wed, 30 May 2007 12:27:24 +0100
Peter Stephenson <pws@csr.com> wrote:
> It would be nice to be able to detect if the index is going to be used
> for something other than extracting a single element and use the first
> index if so, but the current interface doesn't make that easy.

This would do it, but we're now disappearing back down the hole we've
supposedly dug ourselves out of.

Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.37
diff -u -r1.37 params.yo
--- Doc/Zsh/params.yo	21 May 2007 09:30:25 -0000	1.37
+++ Doc/Zsh/params.yo	30 May 2007 12:50:00 -0000
@@ -234,7 +234,10 @@
 Like `tt(r)', but gives the last match.  For associative arrays, gives
 all possible matches. May be used for assigning to ordinary array
 elements, but not for assigning to associative arrays.
-On failure the empty string is returned.
+On failure the empty string is returned for a single match; any
+time a valid subscript is needed (for example, on an assignment
+to a failed element, or in a subscript range) the subscript is
+treated as the location of the first element.
 )
 item(tt(i))(
 Like `tt(r)', but gives the index of the match instead; this may not be
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.129
diff -u -r1.129 params.c
--- Src/params.c	29 May 2007 14:16:03 -0000	1.129
+++ Src/params.c	30 May 2007 12:50:07 -0000
@@ -976,6 +976,9 @@
  * *w is only set if we need to find the end of a word (input; should
  *  be set to 0 by the caller).
  *
+ * flags is the current set of SCANPM_ flags passed down from
+ * the substitution being done.
+ *
  * The final two arguments are to support multibyte characters.
  * If supplied they are set to the length of the character before
  * the index position and the one at the index position.  If
@@ -991,7 +994,7 @@
 
 /**/
 static zlong
-getarg(char **str, int *inv, Value v, int a2, zlong *w,
+getarg(char **str, int *inv, Value v, int a2, zlong *w, int flags,
        int *prevcharlen, int *nextcharlen)
 {
     int hasbeg = 0, word = 0, rev = 0, ind = 0, down = 0, l, i, ishash;
@@ -1324,11 +1327,16 @@
 		     * is ambiguous with KSH_ARRAYS set, but we're
 		     * stuck with that now.
 		     *
-		     * If the index is to be turned into an element,
-		     * return an index that does not point to a valid
+		     * If
+		     * - the index is to be turned into an element
+		     * - we are not in a range of indices, i.e. neither
+		     *   a comma follows nor SCANPM_ENDRANGE is set,
+		     * - we are not assigning,
+		     * then return an index that does not point to a valid
 		     * element (since 0 is treated the same as 1).
 		     */
-		    if (!ind)
+		    if (!ind && *t != ',' &&
+			!(flags & (SCANPM_ENDRANGE|SCANPM_ASSIGNING)))
 			r = len + 1;
 		} else
 		    for (r = 1 + beg, p = ta + beg; *p; r++, p++)
@@ -1555,7 +1563,9 @@
 	     * its index, ensure the element is empty.
 	     * See comments on the array case above.
 	     */
-	    return (down && ind) ? 0 : slen + 1;
+	    return (down && (ind || *t == '.' ||
+			     (flags & (SCANPM_ENDRANGE|SCANPM_ASSIGNING))))
+		? 0 : slen + 1;
 	}
     }
     return r;
@@ -1563,13 +1573,14 @@
 
 /**/
 int
-getindex(char **pptr, Value v, int dq)
+getindex(char **pptr, Value v, int flags)
 {
     int start, end, inv = 0;
     char *s = *pptr, *tbrack;
 
     *s++ = '[';
-    s = parse_subscript(s, dq);	/* Error handled after untokenizing */
+    /* Error in parsing handled after untokenizing */
+    s = parse_subscript(s, flags & SCANPM_DQUOTED);
     /* Now we untokenize everything except inull() markers so we can check *
      * for the '*' and '@' special subscripts.  The inull()s are removed  *
      * in getarg() after we know whether we're doing reverse indexing.    */
@@ -1598,7 +1609,8 @@
 	zlong we = 0, dummy;
 	int startprevlen, startnextlen;
 
-	start = getarg(&s, &inv, v, 0, &we, &startprevlen, &startnextlen);
+	start = getarg(&s, &inv, v, 0, &we, flags,
+		       &startprevlen, &startnextlen);
 
 	if (inv) {
 	    if (!v->isarr && start != 0) {
@@ -1672,7 +1684,8 @@
 
 	    if ((com = (*s == ','))) {
 		s++;
-		end = getarg(&s, &inv, v, 1, &dummy, NULL, NULL);
+		end = getarg(&s, &inv, v, 1, &dummy,
+			     flags | SCANPM_ENDRANGE, NULL, NULL);
 	    } else {
 		end = we ? we : start;
 	    }
@@ -1790,7 +1803,7 @@
 	v->start = 0;
 	v->end = -1;
 	if (bracks > 0 && (*s == '[' || *s == Inbrack)) {
-	    if (getindex(&s, v, (flags & SCANPM_DQUOTED))) {
+	    if (getindex(&s, v, flags)) {
 		*pptr = s;
 		return v;
 	    }
Index: Src/subst.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/subst.c,v
retrieving revision 1.77
diff -u -r1.77 subst.c
--- Src/subst.c	2 Apr 2007 11:00:43 -0000	1.77
+++ Src/subst.c	30 May 2007 12:50:10 -0000
@@ -2008,7 +2008,7 @@
 	    v->isarr = isarr;
 	    v->pm = pm;
 	    v->end = -1;
-	    if (getindex(&s, v, qt) || s == os)
+	    if (getindex(&s, v, qt ? SCANPM_DQUOTED : 0) || s == os)
 		break;
 	}
 	/*
Index: Src/zsh.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.115
diff -u -r1.115 zsh.h
--- Src/zsh.h	28 May 2007 22:57:41 -0000	1.115
+++ Src/zsh.h	30 May 2007 12:50:12 -0000
@@ -1422,6 +1422,7 @@
 #define SCANPM_ASSIGNING  (1<<6)
 #define SCANPM_KEYMATCH   (1<<7)
 #define SCANPM_DQUOTED    (1<<8)
+#define SCANPM_ENDRANGE   (1<<9)
 #define SCANPM_ISVAR_AT   ((-1)<<15)	/* Only sign bit is significant */
 
 /*



-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Peter Stephenson]

On Wed, 30 May 2007 13:54:36 +0100
Peter Stephenson <pws@csr.com> wrote:
> Index: Doc/Zsh/params.yo
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
> retrieving revision 1.37
> diff -u -r1.37 params.yo
> --- Doc/Zsh/params.yo	21 May 2007 09:30:25 -0000	1.37
> +++ Doc/Zsh/params.yo	30 May 2007 12:50:00 -0000
> @@ -234,7 +234,10 @@
>  Like `tt(r)', but gives the last match.  For associative arrays,
> gives all possible matches. May be used for assigning to ordinary
> array elements, but not for assigning to associative arrays.
> -On failure the empty string is returned.
> +On failure the empty string is returned for a single match; any
> +time a valid subscript is needed (for example, on an assignment
> +to a failed element, or in a subscript range) the subscript is
> +treated as the location of the first element.
>  )
>  item(tt(i))(
>  Like `tt(r)', but gives the index of the match instead; this may not

Any strong reaction to this further change for (R)?  I'm tempted to put it
in in the hope it's the best of a bad job.

I think the ideal case would be that a failed (R) returned an index off the
beginning of the array.  This would make it symmetrical with (r), would
make ranges work sensibly, and would make an assignment on failure prepend
the quantity being assigned (rather than override the first element, which
is pretty gross).  However, with the kludge for index 0 as a poor person's
KSH_ARRAYS, and negative numbers counting from the end, there is no index
that's off the start.  The combination of (R) returning an empty element if
it's returning an element, and the start of the array if it's being used as
an index, including the case of ranges and assignments (and, as it will no
doubt turn out, roads, schools, aqueducts, ...) mimics that to some extent.

-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Bart Schaefer]

On Jun 4, 10:49am, Peter Stephenson wrote:
} Subject: Re: Change in FIGNORE behavior
}
} > +On failure the empty string is returned for a single match; any
} > +time a valid subscript is needed (for example, on an assignment
} > +to a failed element, or in a subscript range) the subscript is
} > +treated as the location of the first element.
} 
} Any strong reaction to this further change for (R)? I'm tempted to put
} it in in the hope it's the best of a bad job.

I confess I have not yet had a chance to really even think about it.

I seem to recall a previous conversation on this subject in which the
former behavior (prior to 23440) was as it was so that both (R) and
${array[$array[(I)pattern]}} would return the same result.

} 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[0] (treat it as an invalid identifier) when the
KSH_ARRAYS option is not in effect.  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.

Re: Change in FIGNORE behavior

[Peter Stephenson]

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[0] (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@csr.com>                  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

Re: Change in FIGNORE behavior

[Peter Stephenson]

On Tue, 05 Jun 2007 15:19:34 +0100
Peter Stephenson <pws@csr.com> wrote:
> 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[0] (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.

I've called it KSH_ZERO_SUBSCRIPT because perusal of the documentation
suggests we don't tend to use the word "index".  I've made it off
by default and removed my previous hacks.  In summary (see the new tests
for examples):

  array=(one two three)

With KSH_ZERO_SUBSCRIPT set (old behaviour):
  $array[0]               -> one
  array[(R)notfound]      -> one
  $array[0,2]             -> one two
  array[0]=zero           array -> (zero two three)
  array[0,2]=(new)        array -> (new three)

With KSH_ZERO_SUBSCRIPT not set:
  $array[0]               -> [empty]
  array[(R)notfound]      -> [empty]
  $array[0,2]             -> one two
  array[0]=zero           Error
  array[0,2]=(new)        array -> (new three)

The behaviour with scalar subscripts corresponds exactly (the subscript
code that changed is common to both).  The behaviour with KSH_ARRAYS
set shouldn't have changed at all.  Indices returned by (i) and (I)
haven't changed either.

This is obviously more consistent, but actually it's in many ways safer
than either the original code or my hacked attempts at fixing (R).
array[(R)notfound,(r)notfound] once again refers to the entire array:
the indexes start before the start of the array and finish after the end,
but cover a valid range, so this is not an error.  Also,  code
like
  (( array[unsetval++] = 1 ))
  (( array[unsetval++] = 2 ))
(which is presumably intended to refer to the first two elements of array,
but doesn't) is trapped before it does any damage.  As this shows, There's
a very good chance that code using this "feature" is actually buggy.

Note on implementation:  when retrieving a range it was enough to set
the range to one with no elements to get this to work.  However, there
are hacks in the code when setting arrays such that there wasn't a clean
way of trapping an invalid range when setting an element, so I
introduced a flag in the value structure indicating an invalid range.
Code simply retrieving values shouldn't need to test it.


Index: README
===================================================================
RCS file: /cvsroot/zsh/zsh/README,v
retrieving revision 1.47
diff -u -r1.47 README
--- README	29 May 2007 17:01:08 -0000	1.47
+++ README	15 Jun 2007 09:59:53 -0000
@@ -45,6 +45,31 @@
 applies to expressions with forced splitting such as ${=1+"$@"}, but
 otherwise the case where SH_WORD_SPLIT is not set is unaffected.
 
+In previous versions of the shell it was possible to use index 0 in an
+array or string subscript to refer to the same element as index 1 if the
+option KSH_ARRAYS was not in effect.  This was a limited approximation to
+the full KSH_ARRAYS handling and so was not very useful.  In this version
+of the shell, this behaviour is only provided when the option
+KSH_ZERO_SUBSCRIPT is set.  Note that despite the name this does not provide
+true compatibility with ksh or other shells and KSH_ARRAYS should still be
+used for that purpose.  By default, the option is not set; an array
+subscript that evaluates to 0 returns an empty string or array element and
+attempts to write to an array or string range including only a zero
+subscript are treated as an error.  Writes to otherwise valid ranges that
+also include index zero are allowed; hence for example the assignment
+  array[(R)notfound,(r)notfound]=()
+(where the string "notfound" does not match an element in $array) sets the
+entire array to be empty, as in previous versions of the shell.
+KSH_ZERO_SUBSCRIPT is irrelevant when KSH_ARRAYS is set.  Also as in previous
+versions, attempts to write to non-existent elements at the end of an array
+cause the array to be suitably extended.  This difference means that, for
+example
+  array[(R)notfound]=(replacement)
+is an error if KSH_ZERO_SUBSCRIPT is not set (new behaviour), while
+  array[(r)notfound]=(replacement)
+causes the given value to be appended to the array (same behaviour as
+previous versions).
+
 The "exec" precommand modifier now takes various options for compatibility
 with other shells.  This means that whereas "exec -prog" previously
 tried to execute a command name "-prog", it will now report an error
@@ -77,10 +102,6 @@
 $search starts with "%" considers the "%" to be part of the search
 string as before.
 
-Parameter subscripts of the form ${array[(R)test]} now return the
-empty string if they fail to match.  The previous longstanding behaviour
-was confusing and useless.
-
 The MULTIBYTE option is on by default where it is available; this
 causes many operations to recognise characters as in the current locale.
 Older versions of the shell always assumed a character was one byte.
Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.54
diff -u -r1.54 options.yo
--- Doc/Zsh/options.yo	1 May 2007 22:05:05 -0000	1.54
+++ Doc/Zsh/options.yo	15 Jun 2007 09:59:55 -0000
@@ -1244,6 +1244,31 @@
 word splitting after command and parameter expansion in arguments of an
 assignment; with it, word splitting does not take place in those cases.
 )
+pindex(KSH_ZERO_SUBSCRIPT)
+cindex(arrays, behaviour of index zero)
+item(tt(KSH_ZERO_SUBSCRIPT))(
+Treat use of a subscript of value zero in array or string expressions as a
+reference to the first element, i.e. the element that usually has the
+subscript 1.  Ignored if tt(KSH_ARRAYS) is also set.
+
+If neither this option nor tt(KSH_ARRAYS) is set, accesses to an element of
+an array or string with subscript zero return an empty element or string,
+while attempts to set element zero of an array or string are treated as an
+error.  However, attempts to set an otherwise valid subscript range that
+includes zero will succeed.  For example, if tt(KSH_ZERO_SUBSCRIPT) is not
+set,
+
+example(array[0]=(element))
+
+is an error, while
+
+example(array[0,1]=(element))
+
+is not and will replace the first element of the array.
+
+This option is for compatibility with older versions of the shell and
+is not recommended in new code.
+)
 pindex(POSIX_BUILTINS)
 item(tt(POSIX_BUILTINS) <K> <S>)(
 When this option is set the tt(command) builtin can be used to execute
Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.38
diff -u -r1.38 params.yo
--- Doc/Zsh/params.yo	12 Jun 2007 22:01:38 -0000	1.38
+++ Doc/Zsh/params.yo	15 Jun 2007 09:59:57 -0000
@@ -96,6 +96,14 @@
 option is set, the braced form is the only one that works, as bracketed
 expressions otherwise are not treated as subscripts.
 
+If the tt(KSH_ARRAYS) option is not set, then by default accesses to
+an array element with a subscript that evaluates to zero return an
+empty string, while an attempt to write such an element is treated as
+an error.  For backward compatibility the tt(KSH_ZERO_SUBSCRIPT)
+option can be set to cause subscript values 0 and 1 to be equivalent; see
+the description of the option in ifzman(zmanref(zshoptions))\
+ifnzman(noderef(Description of Options)).
+
 The same subscripting syntax is used for associative arrays, except that
 no arithmetic expansion is applied to var(exp).  However, the parsing
 rules for arithmetic expressions still apply, which affects the way that
@@ -233,26 +241,22 @@
 item(tt(R))(
 Like `tt(r)', but gives the last match.  For associative arrays, gives
 all possible matches. May be used for assigning to ordinary array
-elements, but not for assigning to associative arrays.
-On failure the empty string is returned.
+elements, but not for assigning to associative arrays.  On failure, for
+normal arrays this has the effect of returning the element corresponding to
+subscript 0; this is empty unless one of the options tt(KSH_ARRAYS) or
+tt(KSH_ZERO_SUBSCRIPT) is in effect.
 )
 item(tt(i))(
 Like `tt(r)', but gives the index of the match instead; this may not be
 combined with a second argument.  On the left side of an assignment,
 behaves like `tt(r)'.  For associative arrays, the key part of each pair
 is compared to the pattern, and the first matching key found is the
-result.
-
-On failure, a value one past the end of the array or string is returned.
+result.  On failure substitutes one more than the last currently
+valid index, as discussed under the description of `tt(r)'.
 )
 item(tt(I))(
 Like `tt(i)', but gives the index of the last match, or all possible
-matching keys in an associative array.
-
-On failure the value 0 is returned.  If the option tt(KSH_ARRAYS) is in
-effect, the subscript is still 0 for a failed match; this cannot be
-distinguished from a successful match without testing tt(${array[0]})
-against the pattern.
+matching keys in an associative array.  On failure substitutes 0.
 )
 item(tt(k))(
 If used in a subscript on an associative array, this flag causes the keys
Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.116
diff -u -r1.116 exec.c
--- Src/exec.c	3 Jun 2007 17:44:20 -0000	1.116
+++ Src/exec.c	15 Jun 2007 09:59:58 -0000
@@ -3662,7 +3662,10 @@
 	fprintf(xtrerr, " ))\n");
 	fflush(xtrerr);
     }
-    errflag = 0;
+    if (errflag) {
+	errflag = 0;
+	return 2;
+    }
     /* should test for fabs(val.u.d) < epsilon? */
     return (val.type == MN_INTEGER) ? val.u.l == 0 : val.u.d == 0.0;
 }
Index: Src/glob.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/glob.c,v
retrieving revision 1.58
diff -u -r1.58 glob.c
--- Src/glob.c	21 Jan 2007 22:47:41 -0000	1.58
+++ Src/glob.c	15 Jun 2007 09:59:59 -0000
@@ -1470,7 +1470,7 @@
 		    v.isarr = SCANPM_WANTVALS;
 		    v.pm = NULL;
 		    v.end = -1;
-		    v.inv = 0;
+		    v.flags = 0;
 		    if (getindex(&s, &v, 0) || s == os) {
 			zerr("invalid subscript");
 			restore_globstate(saved);
Index: Src/options.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/options.c,v
retrieving revision 1.36
diff -u -r1.36 options.c
--- Src/options.c	1 May 2007 22:05:05 -0000	1.36
+++ Src/options.c	15 Jun 2007 09:59:59 -0000
@@ -153,9 +153,10 @@
 {{NULL, "interactivecomments",OPT_BOURNE},		 INTERACTIVECOMMENTS},
 {{NULL, "ksharrays",	      OPT_EMULATE|OPT_BOURNE},	 KSHARRAYS},
 {{NULL, "kshautoload",	      OPT_EMULATE|OPT_BOURNE},	 KSHAUTOLOAD},
-{{NULL, "kshglob",            OPT_EMULATE|OPT_KSH},      KSHGLOB},
+{{NULL, "kshglob",	      OPT_EMULATE|OPT_KSH},	 KSHGLOB},
 {{NULL, "kshoptionprint",     OPT_EMULATE|OPT_KSH},	 KSHOPTIONPRINT},
-{{NULL, "kshtypeset",         OPT_EMULATE|OPT_KSH},	 KSHTYPESET},
+{{NULL, "kshtypeset",	      OPT_EMULATE|OPT_KSH},	 KSHTYPESET},
+{{NULL, "kshzerosubscript",   0},			 KSHZEROSUBSCRIPT},
 {{NULL, "listambiguous",      OPT_ALL},			 LISTAMBIGUOUS},
 {{NULL, "listbeep",	      OPT_ALL},			 LISTBEEP},
 {{NULL, "listpacked",	      0},			 LISTPACKED},
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.130
diff -u -r1.130 params.c
--- Src/params.c	12 Jun 2007 15:43:16 -0000	1.130
+++ Src/params.c	15 Jun 2007 10:00:00 -0000
@@ -520,7 +520,7 @@
 	    return;
     }
     v.isarr = (PM_TYPE(v.pm->node.flags) & (PM_ARRAY|PM_HASHED));
-    v.inv = 0;
+    v.flags = 0;
     v.start = 0;
     v.end = -1;
     paramvals[numparamvals] = getstrvalue(&v);
@@ -1298,7 +1298,7 @@
 		    (*ta || ((v->isarr & SCANPM_MATCHMANY) &&
 			     (v->isarr & (SCANPM_MATCHKEY | SCANPM_MATCHVAL |
 					  SCANPM_KEYMATCH))))) {
-		    *inv = v->inv;
+		    *inv = (v->flags & VALFLAG_INV) ? 1 : 0;
 		    *w = v->end;
 		    return 1;
 		}
@@ -1317,19 +1317,6 @@
 			if (pprog && pattry(pprog, *p) && !--num)
 			    return r;
 		    }
-		    /*
-		     * Failed to match.
-		     * If we're returning an index, return 0 to show
-		     * we've gone off the start.  Unfortunately this
-		     * is ambiguous with KSH_ARRAYS set, but we're
-		     * stuck with that now.
-		     *
-		     * If the index is to be turned into an element,
-		     * return an index that does not point to a valid
-		     * element (since 0 is treated the same as 1).
-		     */
-		    if (!ind)
-			r = len + 1;
 		} else
 		    for (r = 1 + beg, p = ta + beg; *p; r++, p++)
 			if (pprog && pattry(pprog, *p) && !--num)
@@ -1549,13 +1536,7 @@
 		    }
 		}
 	    }
-	    /*
-	     * Failed to match.
-	     * If the argument selects an element rather than
-	     * its index, ensure the element is empty.
-	     * See comments on the array case above.
-	     */
-	    return (down && ind) ? 0 : slen + 1;
+	    return down ? 0 : slen + 1;
 	}
     }
     return r;
@@ -1563,13 +1544,14 @@
 
 /**/
 int
-getindex(char **pptr, Value v, int dq)
+getindex(char **pptr, Value v, int flags)
 {
     int start, end, inv = 0;
     char *s = *pptr, *tbrack;
 
     *s++ = '[';
-    s = parse_subscript(s, dq);	/* Error handled after untokenizing */
+    /* Error handled after untokenizing */
+    s = parse_subscript(s, flags & SCANPM_DQUOTED);
     /* Now we untokenize everything except inull() markers so we can check *
      * for the '*' and '@' special subscripts.  The inull()s are removed  *
      * in getarg() after we know whether we're doing reverse indexing.    */
@@ -1654,7 +1636,7 @@
 	    if (start > 0 && (isset(KSHARRAYS) || (v->pm->node.flags & PM_HASHED)))
 		start--;
 	    if (v->isarr != SCANPM_WANTINDEX) {
-		v->inv = 1;
+		v->flags |= VALFLAG_INV;
 		v->isarr = 0;
 		v->start = start;
 		v->end = start + 1;
@@ -1686,7 +1668,32 @@
 	    if (start > 0)
 		start -= startprevlen;
 	    else if (start == 0 && end == 0)
-		end = startnextlen;
+	    {
+		/*
+		 * Strictly, this range is entirely off the
+		 * start of the available index range.
+		 * This can't happen with KSH_ARRAYS; we already
+		 * altered the start index in getarg().
+		 * Are we being strict?
+		 */
+		if (isset(KSHZEROSUBSCRIPT)) {
+		    /*
+		     * We're not.
+		     * Treat this as accessing the first element of the
+		     * array.
+		     */
+		    end = startnextlen;
+		} else {
+		    /*
+		     * We are.  Flag that this range is invalid
+		     * for setting elements.  Set the indexes
+		     * to a range that returns empty for other accesses.
+		     */
+		    v->flags |= VALFLAG_EMPTY;
+		    start = -1;
+		    com = 1;
+		}
+	    }
 	    if (s == tbrack) {
 		s++;
 		if (v->isarr && !com &&
@@ -1755,7 +1762,7 @@
 	else
 	    v = (Value) hcalloc(sizeof *v);
 	v->pm = argvparam;
-	v->inv = 0;
+	v->flags = 0;
 	v->start = ppar - 1;
 	v->end = ppar;
 	if (sav)
@@ -1786,11 +1793,11 @@
 		v->isarr = SCANPM_MATCHMANY;
 	}
 	v->pm = pm;
-	v->inv = 0;
+	v->flags = 0;
 	v->start = 0;
 	v->end = -1;
 	if (bracks > 0 && (*s == '[' || *s == Inbrack)) {
-	    if (getindex(&s, v, (flags & SCANPM_DQUOTED))) {
+	    if (getindex(&s, v, flags)) {
 		*pptr = s;
 		return v;
 	    }
@@ -1830,7 +1837,7 @@
     if (!v)
 	return hcalloc(1);
 
-    if (v->inv && !(v->pm->node.flags & PM_HASHED)) {
+    if ((v->flags & VALFLAG_INV) && !(v->pm->node.flags & PM_HASHED)) {
 	sprintf(buf, "%d", v->start);
 	s = dupstring(buf);
 	return s;
@@ -1911,7 +1918,7 @@
 	return arrdup(nular);
     else if (IS_UNSET_VALUE(v))
 	return arrdup(&nular[1]);
-    if (v->inv) {
+    if (v->flags & VALFLAG_INV) {
 	char buf[DIGBUFSIZE];
 
 	s = arrdup(nular);
@@ -1943,7 +1950,7 @@
 {
     if (!v)
 	return 0;
-    if (v->inv)
+    if (v->flags & VALFLAG_INV)
 	return v->start;
     if (v->isarr) {
 	char **arr = getarrvalue(v);
@@ -1970,7 +1977,7 @@
 
     if (!v) {
 	mn.u.l = 0;
-    } else if (v->inv) {
+    } else if (v->flags & VALFLAG_INV) {
 	mn.u.l = v->start;
     } else if (v->isarr) {
 	char **arr = getarrvalue(v);
@@ -2000,7 +2007,7 @@
 	if (emulation == EMULATE_KSH /* isset(KSHARRAYS) */) {
 	    struct value v;
 	    v.isarr = 1;
-	    v.inv = 0;
+	    v.flags = 0;
 	    v.start = 0;
 	    v.end = -1;
 	    val = getstrvalue(&v);
@@ -2037,6 +2044,11 @@
 	zsfree(val);
 	return;
     }
+    if (v->flags & VALFLAG_EMPTY) {
+	zerr("%s: assignment to invalid subscript range", v->pm->node.nam);
+	zsfree(val);
+	return;
+    }
     v->pm->node.flags &= ~PM_UNSET;
     switch (PM_TYPE(v->pm->node.flags)) {
     case PM_SCALAR:
@@ -2051,7 +2063,7 @@
 
 	    z = dupstring(v->pm->gsu.s->getfn(v->pm));
 	    zlen = strlen(z);
-	    if (v->inv && unset(KSHARRAYS))
+	    if ((v->flags & VALFLAG_INV) && unset(KSHARRAYS))
 		v->start--, v->end--;
 	    if (v->start < 0) {
 		v->start += zlen;
@@ -2176,6 +2188,11 @@
 	     v->pm->node.nam);
 	return;
     }
+    if (v->flags & VALFLAG_EMPTY) {
+	zerr("%s: assignment to invalid subscript range", v->pm->node.nam);
+	freearray(val);
+	return;
+    }
     if (v->start == 0 && v->end == -1) {
 	if (PM_TYPE(v->pm->node.flags) == PM_HASHED)
 	    arrhashsetfn(v->pm, val, 0);
@@ -2194,7 +2211,7 @@
 		 v->pm->node.nam);
 	    return;
 	}
-	if (v->inv && unset(KSHARRAYS)) {
+	if ((v->flags & VALFLAG_INV) && unset(KSHARRAYS)) {
 	    if (v->start > 0)
 		v->start--;
 	    v->end--;
Index: Src/subst.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/subst.c,v
retrieving revision 1.77
diff -u -r1.77 subst.c
--- Src/subst.c	2 Apr 2007 11:00:43 -0000	1.77
+++ Src/subst.c	15 Jun 2007 10:00:00 -0000
@@ -2008,7 +2008,7 @@
 	    v->isarr = isarr;
 	    v->pm = pm;
 	    v->end = -1;
-	    if (getindex(&s, v, qt) || s == os)
+	    if (getindex(&s, v, qt ? SCANPM_DQUOTED : 0) || s == os)
 		break;
 	}
 	/*
@@ -2025,8 +2025,11 @@
 	 * in the subexp stuff or immediately above.
 	 */
 	if ((isarr = v->isarr)) {
-	    /* No way to get here with v->inv != 0, so getvaluearr() *
-	     * is called by getarrvalue(); needn't test PM_HASHED.   */
+	    /*
+	     * No way to get here with v->flags & VALFLAG_INV, so
+	     * getvaluearr() is called by getarrvalue(); needn't test
+	     * PM_HASHED.
+	     */
 	    if (v->isarr == SCANPM_WANTINDEX) {
 		isarr = v->isarr = 0;
 		val = dupstring(v->pm->node.nam);
@@ -2048,8 +2051,9 @@
 		int tmplen = arrlen(v->pm->gsu.a->getfn(v->pm));
 
 		if (v->start < 0)
-		    v->start += tmplen + v->inv;
-		if (!v->inv && (v->start >= tmplen || v->start < 0))
+		    v->start += tmplen + ((v->flags & VALFLAG_INV) ? 1 : 0);
+		if (!(v->flags & VALFLAG_INV) &&
+		    (v->start >= tmplen || v->start < 0))
 		    vunset = 1;
 	    }
 	    if (!vunset) {
Index: Src/zsh.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.115
diff -u -r1.115 zsh.h
--- Src/zsh.h	28 May 2007 22:57:41 -0000	1.115
+++ Src/zsh.h	15 Jun 2007 10:00:00 -0000
@@ -585,12 +585,17 @@
 struct value {
     int isarr;
     Param pm;		/* parameter node                      */
-    int inv;		/* should we return the index ?        */
+    int flags;		/* flags defined below                 */
     int start;		/* first element of array slice, or -1 */
     int end;		/* 1-rel last element of array slice, or -1 */
     char **arr;		/* cache for hash turned into array */
 };
 
+enum {
+    VALFLAG_INV =	0x0001,	/* We are performing inverse subscripting */
+    VALFLAG_EMPTY =	0x0002	/* Subscripted range is empty */
+};
+
 #define MAX_ARRLEN    262144
 
 /********************************************/
@@ -1725,6 +1730,7 @@
     KSHGLOB,
     KSHOPTIONPRINT,
     KSHTYPESET,
+    KSHZEROSUBSCRIPT,
     LISTAMBIGUOUS,
     LISTBEEP,
     LISTPACKED,
Index: Src/Modules/mapfile.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/mapfile.c,v
retrieving revision 1.9
diff -u -r1.9 mapfile.c
--- Src/Modules/mapfile.c	28 May 2007 22:57:41 -0000	1.9
+++ Src/Modules/mapfile.c	15 Jun 2007 10:00:01 -0000
@@ -149,7 +149,7 @@
 	    for (hn = ht->nodes[i]; hn; hn = hn->next) {
 		struct value v;
 
-		v.isarr = v.inv = v.start = 0;
+		v.isarr = v.flags = v.start = 0;
 		v.end = -1;
 		v.arr = NULL;
 		v.pm = (Param) hn;
Index: Src/Modules/parameter.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/parameter.c,v
retrieving revision 1.41
diff -u -r1.41 parameter.c
--- Src/Modules/parameter.c	28 May 2007 22:57:41 -0000	1.41
+++ Src/Modules/parameter.c	15 Jun 2007 10:00:01 -0000
@@ -180,7 +180,7 @@
 	    Cmdnam cn = zshcalloc(sizeof(*cn));
 	    struct value v;
 
-	    v.isarr = v.inv = v.start = 0;
+	    v.isarr = v.flags = v.start = 0;
 	    v.end = -1;
 	    v.arr = NULL;
 	    v.pm = (Param) hn;
@@ -341,7 +341,7 @@
 	for (hn = ht->nodes[i]; hn; hn = hn->next) {
 	    struct value v;
 
-	    v.isarr = v.inv = v.start = 0;
+	    v.isarr = v.flags = v.start = 0;
 	    v.end = -1;
 	    v.arr = NULL;
 	    v.pm = (Param) hn;
@@ -701,7 +701,7 @@
 	    struct value v;
 	    char *val;
 
-	    v.isarr = v.inv = v.start = 0;
+	    v.isarr = v.flags = v.start = 0;
 	    v.end = -1;
 	    v.arr = NULL;
 	    v.pm = (Param) hn;
@@ -1325,7 +1325,7 @@
 	    struct value v;
 	    char *val;
 
-	    v.isarr = v.inv = v.start = 0;
+	    v.isarr = v.flags = v.start = 0;
 	    v.end = -1;
 	    v.arr = NULL;
 	    v.pm = (Param) hn;
@@ -1554,7 +1554,7 @@
 	    struct value v;
 	    char *val;
 
-	    v.isarr = v.inv = v.start = 0;
+	    v.isarr = v.flags = v.start = 0;
 	    v.end = -1;
 	    v.arr = NULL;
 	    v.pm = (Param) hn;
Index: Src/Zle/complete.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complete.c,v
retrieving revision 1.37
diff -u -r1.37 complete.c
--- Src/Zle/complete.c	29 May 2007 17:01:09 -0000	1.37
+++ Src/Zle/complete.c	15 Jun 2007 10:00:02 -0000
@@ -1139,7 +1139,7 @@
 	    for (cp = compkparams,
 		 pp = compkpms; cp->name; cp++, pp++)
 		if (!strcmp(hn->nam, cp->name)) {
-		    v.isarr = v.inv = v.start = 0;
+		    v.isarr = v.flags = v.start = 0;
 		    v.end = -1;
 		    v.arr = NULL;
 		    v.pm = (Param) hn;
Index: Test/C01arith.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C01arith.ztst,v
retrieving revision 1.11
diff -u -r1.11 C01arith.ztst
--- Test/C01arith.ztst	12 Feb 2007 16:43:42 -0000	1.11
+++ Test/C01arith.ztst	15 Jun 2007 10:00:02 -0000
@@ -91,8 +91,13 @@
 >3.5
 >4
 
-  (( newarray[unsetvar]++ ))
-  (( newarray[unsetvar]++ ))
+  (( newarray[unsetvar] = 1 ))
+2:error using unset variable as index
+?(eval):1:  assignment to invalid subscript range
+
+  integer setvar=1
+  (( newarray[setvar]++ ))
+  (( newarray[setvar]++ ))
   print ${(t)newarray} ${#newarray} ${newarray[1]}
 0:setting array elements in math context
 >array 1 2
Index: Test/D05array.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D05array.ztst,v
retrieving revision 1.2
diff -u -r1.2 D05array.ztst
--- Test/D05array.ztst	30 Mar 2004 16:35:38 -0000	1.2
+++ Test/D05array.ztst	15 Jun 2007 10:00:02 -0000
@@ -30,12 +30,12 @@
 >..
 
   echo .$foo[0].
-0:Treat 0 like 1
->.a.
+0:Treat 0 as empty
+>..
 
   echo .$foo[0,0].
-0:Treat 0,0 like 1,1.
->.a.
+0:Treat 0,0 as empty
+>..
 
   echo .$foo[0,1].
 0:Another weird way to access the first element
Index: Test/D06subscript.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D06subscript.ztst,v
retrieving revision 1.10
diff -u -r1.10 D06subscript.ztst
--- Test/D06subscript.ztst	21 May 2007 09:30:26 -0000	1.10
+++ Test/D06subscript.ztst	15 Jun 2007 10:00:02 -0000
@@ -182,3 +182,56 @@
   echo X${${l##*}[-1]}X
 0:Negative index applied to substition result from empty array
 >XX
+
+  array=(one two three four)
+  print X$array[0]X
+0:Element zero is empty if KSH_ZERO_SUBSCRIPT is off.
+>XX
+
+  array[0]=fumble
+1:Can't set element zero if KSH_ZERO_SUBSCRIPT is off.
+?(eval):1: array: assignment to invalid subscript range
+
+  print X$array[(R)notfound]X
+0:(R) returns empty if not found if KSH_ZERO_SUBSCRIPT is off.
+>XX
+
+  setopt KSH_ZERO_SUBSCRIPT
+  print X$array[0]X
+0:Element zero is element one if KSH_ZERO_SUBSCRIPT is on.
+>XoneX
+
+  array[0]=fimble
+  print $array
+0:Can set element zero if KSH_ZERO_SUBSCRIPT is on.
+>fimble two three four
+
+  print X$array[(R)notfound]X
+0:(R) yuckily returns the first element on failure withe KSH_ZERO_SUBSCRIPT
+>XfimbleX
+
+  unsetopt KSH_ZERO_SUBSCRIPT
+  array[(R)notfound,(r)notfound]=(help help here come the seventies retreads)
+  print $array
+0:[(R)notfound,(r)notfound] replaces the whole array
+>help help here come the seventies retreads
+
+  string="Why, if it isn't Officer Dibble"
+  print "[${string[0]}][${string[1]}][${string[0,3]}]"
+0:String subscripts with KSH_ZERO_SUBSCRIPT unset
+>[][W][Why]
+
+  setopt KSH_ZERO_SUBSCRIPT
+  print "[${string[0]}][${string[1]}][${string[0,3]}]"
+0:String subscripts with KSH_ZERO_SUBSCRIPT set
+>[W][W][Why]
+
+  unsetopt KSH_ZERO_SUBSCRIPT
+  string[0,3]="Goodness"
+  print $string
+0:Assignment to chunk of string ignores element 0
+>Goodness, if it isn't Officer Dibble
+
+  string[0]=!
+1:Can't set only element zero of string
+?(eval):1: string: assignment to invalid subscript range
Index: Test/D07multibyte.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D07multibyte.ztst,v
retrieving revision 1.17
diff -u -r1.17 D07multibyte.ztst
--- Test/D07multibyte.ztst	29 May 2007 14:50:29 -0000	1.17
+++ Test/D07multibyte.ztst	15 Jun 2007 10:00:02 -0000
@@ -87,7 +87,7 @@
   s=é
   print A${s[-2]}A B${s[-1]}B C${s[0]}C D${s[1]}D E${s[2]}E
 0:Out of range subscripts with multibyte characters
->AA BéB CéC DéD EE
+>AA BéB CC DéD EE
 
   print ${a[(i)é]} ${a[(I)é]} ${a[${a[(i)é]},${a[(I)é]}]}
 0:Reverse indexing with multibyte characters
Index: Test/E01options.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/E01options.ztst,v
retrieving revision 1.20
diff -u -r1.20 E01options.ztst
--- Test/E01options.ztst	29 May 2007 14:50:29 -0000	1.20
+++ Test/E01options.ztst	15 Jun 2007 10:00:03 -0000
@@ -521,7 +521,7 @@
 >one one[2]
 >one two three
 >one two three two
->one one two three
+>one two three
 
   fpath=(.)
   echo >foo 'echo foo loaded; foo() { echo foo run; }'


-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Stephane Chazelas]

On Fri, Jun 15, 2007 at 11:09:06AM +0100, Peter Stephenson wrote:
[...]
>   array=(one two three)
> 
> With KSH_ZERO_SUBSCRIPT set (old behaviour):
>   $array[0]               -> one
>   array[(R)notfound]      -> one
>   $array[0,2]             -> one two
[...]

Hi Peter,

why not "one two three" there (0, 1, 2)?

-- 
Stéphane

Re: Change in FIGNORE behavior

[Peter Stephenson]

Stephane Chazelas wrote:
> On Fri, Jun 15, 2007 at 11:09:06AM +0100, Peter Stephenson wrote:
> [...]
> >   array=(one two three)
> > 
> > With KSH_ZERO_SUBSCRIPT set (old behaviour):
> >   $array[0]               -> one
> >   array[(R)notfound]      -> one
> >   $array[0,2]             -> one two
> [...]
> 
> Hi Peter,
> 
> why not "one two three" there (0, 1, 2)?

You're thinking of the KSH_ARRAYS option, which does have the effect you
say.  The old behaviour of the shell as shown above really was
that inconsistent... if you asked for 0 or 1 you got "one", if you asked
for 2 you got "two", but if you asked for the range 0 to 2 you got not
0 and 1 and 2, but just 1 and 2.  That's why we want to remove that
behaviour (at least by default).

-- 
Peter Stephenson <pws@csr.com>                  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

Re: Change in FIGNORE behavior

[Peter Stephenson]

Peter Stephenson wrote:
>  array=(one two three)
>
> With KSH_ZERO_SUBSCRIPT set (old behaviour):
>   $array[0]               -> one
>   array[(R)notfound]      -> one
>   $array[0,2]             -> one two
>   array[0]=zero           array -> (zero two three)
>   array[0,2]=(new)        array -> (new three)
> 
> With KSH_ZERO_SUBSCRIPT not set:
>   $array[0]               -> [empty]
>   array[(R)notfound]      -> [empty]
>   $array[0,2]             -> one two
>   array[0]=zero           Error
>   array[0,2]=(new)        array -> (new three)

As there was no further comment (except for Stephane's hint that the the
general reaction was along the lines of "you mean we used to do
*what*?") I've committed this.

I wonder if it's worth adding an option to emulate so you can "emulate
-v 4.2"?  It would be highly imperfect since only the MULTIBYTE and
KSH_ZERO_SUBSCRIPT options are useful for this purpose; you're stuck
with anything else.

-- 
Peter Stephenson <pws@csr.com>                  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

Version emulation (Re: Change in FIGNORE behavior)

[Bart Schaefer]

On Jun 18,  2:32pm, Peter Stephenson wrote:
} Subject: Re: Change in FIGNORE behavior
}
} I wonder if it's worth adding an option to emulate so you can "emulate
} -v 4.2"?  It would be highly imperfect since only the MULTIBYTE and
} KSH_ZERO_SUBSCRIPT options are useful for this purpose; you're stuck
} with anything else.

I just noticed this, and although it's a pleasant-sounding idea I don't
think we want to proceed in that direction.  Before you know it someone
will want to be able to say "emulate -v 2.6" to get back the different
handling of literal/lexical history, and similar lunacy.