extended braces syntax, {1..32..-03}

extended braces syntax, {1..32..-03}

[Mikael Magnusson]

This patch adds the syntax {start..end..step} to brace expansion. It
also allows negative numbers to be used (this was allowed when
braceccl was set before, which worked inconsistently). It also fixes
up zero-padding with negative numbers. You can specify zeropadding in
the step, as well as a negative step. Using a negative step rather
than reversing the order makes a difference as shown here:

% echo {1..32..4}
1 5 9 13 17 21 25 29
% echo {1..32..-4}
29 25 21 17 13 9 5 1
% echo {32..1..4}
32 28 24 20 16 12 8 4
% echo {32..1..-4}
4 8 12 16 20 24 28 32

The basic syntax is stolen/borrowed from bash, but bash does not allow
negative steps.

Missing still is documentation, but I've had this lying around since
august so I figured I'd post it and see if anyone wants to change
anything first.

Zero-padding works like this:

% echo {01..4}
01 02 03 04
% echo {01..-4}
01 00 -1 -2 -3 -4
% echo {1..-04}
001 000 -01 -02 -03 -04
% echo {1..-4..01}
01 00 -1 -2 -3 -4
% echo {1..-4..-02}
-03 -01 001

Originally i had the same number of zeroes regardless of the minus
sign, but bash does it this way, so I figured I'd be consistent with
that.

The code is admittedly somewhat cryptic in places.

Here's a link to the patch,
http://mika.l3ib.org/patches/zsh-extended-braces.patch
And here's the patch

>From 6fa4a778632320f234f0b9c1f477f5cd3a66a5ff Mon Sep 17 00:00:00 2001
From: Mikael Magnusson <mikachu@gmail.com>
Date: Wed, 7 Jul 2010 00:12:25 +0200
Subject: [PATCH] Add {1..10..2} syntax, allow negative numbers without
braceccl set

---
 Src/glob.c |   71 +++++++++++++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/Src/glob.c b/Src/glob.c
index c552e6c..5f68135 100644
--- a/Src/glob.c
+++ b/Src/glob.c
@@ -1924,14 +1924,29 @@ hasbraces(char *str)
 	case Inbrace:
 	    if (!lbr) {
 		lbr = str - 1;
+		if (*str == '-')
+		    str++;
 		while (idigit(*str))
 		    str++;
 		if (*str == '.' && str[1] == '.') {
-		    str++;
-		    while (idigit(*++str));
+		    str++; str++;
+		    if (*str == '-')
+			str++;
+		    while (idigit(*str))
+			str++;
 		    if (*str == Outbrace &&
 			(idigit(lbr[1]) || idigit(str[-1])))
 			return 1;
+		    else if (*str == '.' && str[1] == '.') {
+			str++; str++;
+			if (*str == '-')
+			    str++;
+			while (idigit(*str))
+			    str++;
+			if (*str == Outbrace &&
+			    (idigit(lbr[1]) || idigit(str[-1])))
+			    return 1;
+		    }
 		}
 	    } else {
 		char *s = --str;
@@ -2061,18 +2076,20 @@ xpandbraces(LinkList list, LinkNode *np)
 	} else if (bc == 1) {
 	    if (*str2 == Comma)
 		++comma;	/* we have {foo,bar} */
-	    else if (*str2 == '.' && str2[1] == '.')
+	    else if (*str2 == '.' && str2[1] == '.') {
 		dotdot++;	/* we have {num1..num2} */
+		++str2;
+	    }
 	}
     DPUTS(bc, "BUG: unmatched brace in xpandbraces()");
     if (!comma && dotdot) {
 	/* Expand range like 0..10 numerically: comma or recursive
 	   brace expansion take precedence. */
-	char *dots, *p;
+	char *dots, *p, *dots2 = NULL;
 	LinkNode olast = last;
 	/* Get the first number of the range */
-	int rstart = zstrtol(str+1,&dots,10), rend = 0, err = 0, rev = 0;
-	int wid1 = (dots - str) - 1, wid2 = (str2 - dots) - 2;
+	int rstart = zstrtol(str+1,&dots,10), rend = 0, err = 0, rev = 0, rincr = 1;
+	int wid1 = (dots - str) - 1, wid2 = (str2 - dots) - 2, wid3 = 0;
 	int strp = str - str3;

 	if (dots == str + 1 || *dots != '.' || dots[1] != '.')
@@ -2080,23 +2097,53 @@ xpandbraces(LinkList list, LinkNode *np)
 	else {
 	    /* Get the last number of the range */
 	    rend = zstrtol(dots+2,&p,10);
-	    if (p == dots+2 || p != str2)
+	    if (p == dots+2)
 		err++;
+	    /* check for {num1..num2..incr} */
+	    if (p != str2) {
+		wid2 = (p - dots) - 2;
+		dots2 = p;
+		if (dotdot == 2 && *p == '.' && p[1] == '.') {
+		    rincr = zstrtol(p+2, &p, 10);
+		    wid3 = p - dots2 - 2;
+		    if (p != str2 || !rincr)
+			err++;
+		} else
+		    err++;
+	    }
 	}
 	if (!err) {
 	    /* If either no. begins with a zero, pad the output with   *
-	     * zeroes. Otherwise, choose a min width to suppress them. */
-	    int minw = (str[1] == '0') ? wid1 : (dots[2] == '0' ) ? wid2 :
-		(wid2 > wid1) ? wid1 : wid2;
+	     * zeroes. Otherwise, set min width to 0 to suppress them.
+	     * str+1 is the first number in the range, dots+2 the last,
+	     * and dots2+2 is the increment if that's given. */
+	    /* TODO: sorry about this */
+	    int minw = (str[1] == '0' || (str[1] == '-' && str[2] == '0'))
+		       ? wid1
+		       : (dots[2] == '0' || (dots[2] == '-' && dots[3] == '0'))
+		       ? wid2
+		       : (dots2 && (dots2[2] == '0' ||
+				    (dots2[2] == '-' && dots2[3] == '0')))
+		       ? wid3
+		       : 0;
+	    if (rincr < 0) {
+		/* Handle negative increment */
+		rincr = -rincr;
+		rev = !rev;
+	    }
 	    if (rstart > rend) {
 		/* Handle decreasing ranges correctly. */
 		int rt = rend;
 		rend = rstart;
 		rstart = rt;
-		rev = 1;
+		rev = !rev;
+	    } else if (rincr > 1) {
+		/* when incr > 1, range is aligned to the highest number of str1,
+		 * compensate for this so that it is aligned to the first number */
+		rend -= (rend - rstart) % rincr;
 	    }
 	    uremnode(list, node);
-	    for (; rend >= rstart; rend--) {
+	    for (; rend >= rstart; rend -= rincr) {
 		/* Node added in at end, so do highest first */
 		p = dupstring(str3);
 		sprintf(p + strp, "%0*d", minw, rend);
-- 
1.7.3



-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Peter Stephenson]

On Sun, 5 Dec 2010 16:41:20 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> This patch adds the syntax {start..end..step} to brace expansion. It
> also allows negative numbers to be used (this was allowed when
> braceccl was set before, which worked inconsistently). It also fixes
> up zero-padding with negative numbers. You can specify zeropadding in
> the step, as well as a negative step.
>...
> Missing still is documentation, but I've had this lying around since
> august so I figured I'd post it and see if anyone wants to change
> anything first.

As long as we tests that pass, it's OK by me.

Embarrassingly, there isn't a set of tests for brace expansion at the
moment, though a few aspects are covered in other tests.  Here is a
short 'before' set of tests (I tried it out with the patch applied even
though it doesn't test the new features).

Index: Test/.distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/.distfiles,v
retrieving revision 1.26
diff -p -u -r1.26 .distfiles
--- Test/.distfiles	24 Apr 2009 09:11:59 -0000	1.26
+++ Test/.distfiles	5 Dec 2010 17:23:35 -0000
@@ -28,6 +28,7 @@ D05array.ztst
 D06subscript.ztst
 D07multibyte.ztst
 D08cmdsubst.ztst
+D09brace.ztst
 E01options.ztst
 E02xtrace.ztst
 Makefile.in
Index: Test/D09brace.ztst
===================================================================
RCS file: Test/D09brace.ztst
diff -N Test/D09brace.ztst
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ Test/D09brace.ztst	5 Dec 2010 17:23:35 -0000
@@ -0,0 +1,52 @@
+# Tests for brace expansion
+
+%prep
+
+  foo=(a b c)
+  arr=(foo bar baz)
+
+%test
+
+  print X{1,2,{3..6},7,8}Y
+0:Basic brace expansion
+>X1Y X2Y X3Y X4Y X5Y X6Y X7Y X8Y
+
+  print ${foo}{one,two,three}$arr
+0:Brace expansion with arrays, no RC_EXPAND_PARAM
+>a b conefoo ctwofoo cthreefoo bar baz
+
+  print ${^foo}{one,two,three}$arr
+0:Brace expansion with arrays, with RC_EXPAND_PARAM (1)
+>aonefoo atwofoo athreefoo bonefoo btwofoo bthreefoo conefoo ctwofoo cthreefoo bar baz
+
+  print ${foo}{one,two,three}$^arr
+0:Brace expansion with arrays, with RC_EXPAND_PARAM (2)
+>a b conefoo ctwofoo cthreefoo conebar ctwobar cthreebar conebaz ctwobaz cthreebaz
+
+  print ${^foo}{one,two,three}$^arr
+0:Brace expansion with arrays, with RC_EXPAND_PARAM (3)
+>aonefoo atwofoo athreefoo aonebar atwobar athreebar aonebaz atwobaz athreebaz bonefoo btwofoo bthreefoo bonebar btwobar bthreebar bonebaz btwobaz bthreebaz conefoo ctwofoo cthreefoo conebar ctwobar cthreebar conebaz ctwobaz cthreebaz
+
+  print X{01..4}Y
+0:Numeric range expansion, padding (1)
+>X01Y X02Y X03Y X04Y
+
+  print X{1..04}Y
+0:Numeric range expansion, padding (2)
+>X01Y X02Y X03Y X04Y
+
+  print X{7..12}Y
+0:Numeric range expansion, padding (or not) (3)
+>X7Y X8Y X9Y X10Y X11Y X12Y
+
+  print X{07..12}Y
+0:Numeric range expansion, padding (4)
+>X07Y X08Y X09Y X10Y X11Y X12Y
+
+  print X{7..012}Y
+0:Numeric range expansion, pading (5)
+>X007Y X008Y X009Y X010Y X011Y X012Y
+
+  print X{4..1}Y
+0:Numeric range expansion, decreasing
+>X4Y X3Y X2Y X1Y

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: extended braces syntax, {1..32..-03}

[Mikael Magnusson]

On 5 December 2010 18:25, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Sun, 5 Dec 2010 16:41:20 +0100
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> This patch adds the syntax {start..end..step} to brace expansion. It
>> also allows negative numbers to be used (this was allowed when
>> braceccl was set before, which worked inconsistently). It also fixes
>> up zero-padding with negative numbers. You can specify zeropadding in
>> the step, as well as a negative step.
>>...
>> Missing still is documentation, but I've had this lying around since
>> august so I figured I'd post it and see if anyone wants to change
>> anything first.
>
> As long as we [have] tests that pass, it's OK by me.
>
> Embarrassingly, there isn't a set of tests for brace expansion at the
> moment, though a few aspects are covered in other tests.  Here is a
> short 'before' set of tests (I tried it out with the patch applied even
> though it doesn't test the new features).

Here's a patch that adds documentation and any tests I could think of
(it includes your patch (you had a typo "pading" on one line)).

I hesitated a bit on what the ordinal form of the variable "n3" is but
went with n3th instead of n3rd despite the latter being funnier.

http://mika.l3ib.org/patches/zsh-braces-test-docs.patch

>From a59420f1cd5f9c440cedde08cec87c68939e16c8 Mon Sep 17 00:00:00 2001
From: Mikael Magnusson <mikachu@gmail.com>
Date: Sun, 5 Dec 2010 19:57:51 +0100
Subject: [PATCH] Add documentation and tests for braces

---
 Doc/Zsh/expn.yo    |   13 ++++++-
 Test/.distfiles    |    1 +
 Test/D09brace.ztst |   99 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 112 insertions(+), 1 deletions(-)
 create mode 100644 Test/D09brace.ztst

diff --git a/Doc/Zsh/expn.yo b/Doc/Zsh/expn.yo
index 585e8a9..b904621 100644
--- a/Doc/Zsh/expn.yo
+++ b/Doc/Zsh/expn.yo
@@ -1354,9 +1354,20 @@ where var(n1) and var(n2) are integers,
 is expanded to every number between
 var(n1) and var(n2) inclusive.  If either number begins with a
 zero, all the resulting numbers will be padded with leading zeroes to
-that minimum width.  If the numbers are in decreasing order the
+that minimum width, but for negative numbers the tt(-) character is also
+included in the width.  If the numbers are in decreasing order the
 resulting sequence will also be in decreasing order.

+An expression of the form `tt({)var(n1)tt(..)var(n2)tt(..)var(n3)tt(})',
+where var(n1), var(n2), and var(n3) are integers,
+is expanded as above, but only every var(n3)th number starting from var(n1)
+is output.  If var(n3) is negative the numbers are output in reverse order,
+this is slightly different from simply swapping var(n1) and var(n2) in the case
+that the step var(n3) doesn't evenly divide the range.  Zero padding can be
+specified in any of the three numbers, specifying it in the third can be useful
+to pad for example `tt({-99..100..01})' which is not possible to
specify by putting a
+0 on either of the first two numbers (i.e. pad to two characters).
+
 If a brace expression matches none of the above forms, it is left
 unchanged, unless the option tt(BRACE_CCL) (an abbreviation for `brace
 character class') is set.
diff --git a/Test/.distfiles b/Test/.distfiles
index 7376cec..0e69174 100644
--- a/Test/.distfiles
+++ b/Test/.distfiles
@@ -28,6 +28,7 @@ D05array.ztst
 D06subscript.ztst
 D07multibyte.ztst
 D08cmdsubst.ztst
+D09brace.ztst
 E01options.ztst
 E02xtrace.ztst
 Makefile.in
diff --git a/Test/D09brace.ztst b/Test/D09brace.ztst
new file mode 100644
index 0000000..d0ec93c
--- /dev/null
+++ b/Test/D09brace.ztst
@@ -0,0 +1,99 @@
+# Tests for brace expansion
+
+%prep
+
+  foo=(a b c)
+  arr=(foo bar baz)
+
+%test
+
+  print X{1,2,{3..6},7,8}Y
+0:Basic brace expansion
+>X1Y X2Y X3Y X4Y X5Y X6Y X7Y X8Y
+
+  print ${foo}{one,two,three}$arr
+0:Brace expansion with arrays, no RC_EXPAND_PARAM
+>a b conefoo ctwofoo cthreefoo bar baz
+
+  print ${^foo}{one,two,three}$arr
+0:Brace expansion with arrays, with RC_EXPAND_PARAM (1)
+>aonefoo atwofoo athreefoo bonefoo btwofoo bthreefoo conefoo ctwofoo
cthreefoo bar baz
+
+  print ${foo}{one,two,three}$^arr
+0:Brace expansion with arrays, with RC_EXPAND_PARAM (2)
+>a b conefoo ctwofoo cthreefoo conebar ctwobar cthreebar conebaz
ctwobaz cthreebaz
+
+  print ${^foo}{one,two,three}$^arr
+0:Brace expansion with arrays, with RC_EXPAND_PARAM (3)
+>aonefoo atwofoo athreefoo aonebar atwobar athreebar aonebaz atwobaz
athreebaz bonefoo btwofoo bthreefoo bonebar btwobar bthreebar bonebaz
btwobaz bthreebaz conefoo ctwofoo cthreefoo conebar ctwobar cthreebar
conebaz ctwobaz cthreebaz
+
+  print X{01..4}Y
+0:Numeric range expansion, padding (1)
+>X01Y X02Y X03Y X04Y
+
+  print X{1..04}Y
+0:Numeric range expansion, padding (2)
+>X01Y X02Y X03Y X04Y
+
+  print X{7..12}Y
+0:Numeric range expansion, padding (or not) (3)
+>X7Y X8Y X9Y X10Y X11Y X12Y
+
+  print X{07..12}Y
+0:Numeric range expansion, padding (4)
+>X07Y X08Y X09Y X10Y X11Y X12Y
+
+  print X{7..012}Y
+0:Numeric range expansion, padding (5)
+>X007Y X008Y X009Y X010Y X011Y X012Y
+
+  print X{4..1}Y
+0:Numeric range expansion, decreasing
+>X4Y X3Y X2Y X1Y
+
+  print X{1..4}{1..4}Y
+0:Numeric range expansion, combined braces
+>X11Y X12Y X13Y X14Y X21Y X22Y X23Y X24Y X31Y X32Y X33Y X34Y X41Y
X42Y X43Y X44Y
+
+  print X{-4..4}Y
+0:Numeric range expansion, negative numbers (1)
+>X-4Y X-3Y X-2Y X-1Y X0Y X1Y X2Y X3Y X4Y
+
+  print X{4..-4}Y
+0:Numeric range expansion, negative numbers (2)
+>X4Y X3Y X2Y X1Y X0Y X-1Y X-2Y X-3Y X-4Y
+
+  print X{004..-4..2}Y
+0:Numeric range expansion, stepping and padding (1)
+>X004Y X002Y X000Y X-02Y X-04Y
+
+  print X{4..-4..02}Y
+0:Numeric range expansion, stepping and padding (1)
+>X04Y X02Y X00Y X-2Y X-4Y
+
+  print X{1..32..3}Y
+0:Numeric range expansion, step alignment (1)
+>X1Y X4Y X7Y X10Y X13Y X16Y X19Y X22Y X25Y X28Y X31Y
+
+  print X{1..32..-3}Y
+0:Numeric range expansion, step alignment (2)
+>X31Y X28Y X25Y X22Y X19Y X16Y X13Y X10Y X7Y X4Y X1Y
+
+  print X{32..1..3}Y
+0:Numeric range expansion, step alignment (3)
+>X32Y X29Y X26Y X23Y X20Y X17Y X14Y X11Y X8Y X5Y X2Y
+
+  print X{32..1..-3}Y
+0:Numeric range expansion, step alignment (4)
+>X2Y X5Y X8Y X11Y X14Y X17Y X20Y X23Y X26Y X29Y X32Y
+
+  setopt brace_ccl
+  print X{za-q521}Y
+  unsetopt brace_ccl
+0:BRACE_CCL on
+>X1Y X2Y X5Y XaY XbY XcY XdY XeY XfY XgY XhY XiY XjY XkY XlY XmY XnY
XoY XpY XqY XzY
+
+  print X{za-q521}Y
+0:BRACE_CCL off
+>X{za-q521}Y
+
-- 
1.7.3



-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Mikael Magnusson]

On 5 December 2010 20:17, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 5 December 2010 18:25, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> On Sun, 5 Dec 2010 16:41:20 +0100
>> Mikael Magnusson <mikachu@gmail.com> wrote:
>>> This patch adds the syntax {start..end..step} to brace expansion. It
>>> also allows negative numbers to be used (this was allowed when
>>> braceccl was set before, which worked inconsistently). It also fixes
>>> up zero-padding with negative numbers. You can specify zeropadding in
>>> the step, as well as a negative step.
>>>...
>>> Missing still is documentation, but I've had this lying around since
>>> august so I figured I'd post it and see if anyone wants to change
>>> anything first.
>>
>> As long as we [have] tests that pass, it's OK by me.
>>
>> Embarrassingly, there isn't a set of tests for brace expansion at the
>> moment, though a few aspects are covered in other tests.  Here is a
>> short 'before' set of tests (I tried it out with the patch applied even
>> though it doesn't test the new features).
>
> Here's a patch that adds documentation and any tests I could think of
> (it includes your patch (you had a typo "pading" on one line)).

Ah, I missed you already committed the tests, here's an incremental patch
http://mika.l3ib.org/patches/zsh-braces-test-docs-incr.patch

-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Mikael Magnusson]

On 5 December 2010 20:25, Mikael Magnusson <mikachu@gmail.com> wrote:
>
> Ah, I missed you already committed the tests, here's an incremental patch
> http://mika.l3ib.org/patches/zsh-braces-test-docs-incr.patch

Not sure if it's worth mentioning in the NEWS file, but you could use
negative start/end numbers if brace_ccl was set, which is a bit weird.
(This is because it was only prevented in hasbraces() and not in
xpandbraces()).

I also just noticed that my code accepts a single - as the number 0,
should I fix that? ie {-..2} expands to 0 1 2.

-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Richard Hartmann]

On Sun, Dec 5, 2010 at 16:41, Mikael Magnusson <mikachu@gmail.com> wrote:

> % echo {1..-04}
> 001 000 -01 -02 -03 -04

Why is there extra padding for 001 and 000?


Richard

Re: extended braces syntax, {1..32..-03}

[Mikael Magnusson]

On 6 December 2010 21:57, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> On Sun, Dec 5, 2010 at 16:41, Mikael Magnusson <mikachu@gmail.com> wrote:
>
>> % echo {1..-04}
>> 001 000 -01 -02 -03 -04
>
> Why is there extra padding for 001 and 000?
>
>> % echo {1..-4..01}
>> 01 00 -1 -2 -3 -4
>> % echo {1..-4..-02}
>> -03 -01 001
>>
>> Originally i had the same number of zeroes regardless of the minus
sign, but bash does it this way, so I figured I'd be consistent with
that.

-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Richard Hartmann]

On Sun, Dec 5, 2010 at 22:32, Mikael Magnusson <mikachu@gmail.com> wrote:

> I also just noticed that my code accepts a single - as the number 0,
> should I fix that? ie {-..2} expands to 0 1 2.

Personally, I think yes. It's not a useful feature, mathematically
wrong and hogs a special char that might be used for some future
feature.


Richard

Re: extended braces syntax, {1..32..-03}

[Mikael Magnusson]

On 6 December 2010 22:02, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> On Sun, Dec 5, 2010 at 22:32, Mikael Magnusson <mikachu@gmail.com> wrote:
>
>> I also just noticed that my code accepts a single - as the number 0,
>> should I fix that? ie {-..2} expands to 0 1 2.
>
> Personally, I think yes. It's not a useful feature, mathematically
> wrong and hogs a special char that might be used for some future
> feature.

I actually realized it's not my fault, it always did that :). (but you
still needed setopt braceccl to expand them before the patch).

-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Richard Hartmann]

On Mon, Dec 6, 2010 at 22:00, Mikael Magnusson <mikachu@gmail.com> wrote:

>>> Originally i had the same number of zeroes regardless of the minus
> sign, but bash does it this way, so I figured I'd be consistent with
> that.

Oups. Can I claim "too stupid to read" in my defense?

While I can see the advantage in being compatible with Bash, this
behavior is arguably a bug. If you want, I can pester them about
changing their behavior. Or you decide to change it. Or I just shut up
:)


Richard

Re: extended braces syntax, {1..32..-03}

[Richard Hartmann]

On Mon, Dec 6, 2010 at 22:04, Mikael Magnusson <mikachu@gmail.com> wrote:

> I actually realized it's not my fault, it always did that :). (but you
> still needed setopt braceccl to expand them before the patch).

Also a bug imo. But as it's been that way, changing it is probably not
a option, is it?


Richard

Re: extended braces syntax, {1..32..-03}

[Mikael Magnusson]

On 6 December 2010 22:17, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> On Mon, Dec 6, 2010 at 22:00, Mikael Magnusson <mikachu@gmail.com> wrote:
>
>>>> Originally i had the same number of zeroes regardless of the minus
>> sign, but bash does it this way, so I figured I'd be consistent with
>> that.
>
> Oups. Can I claim "too stupid to read" in my defense?
>
> While I can see the advantage in being compatible with Bash, this
> behavior is arguably a bug. If you want, I can pester them about
> changing their behavior. Or you decide to change it. Or I just shut up
> :)

I just tested in C (printf) and it does it this way too,
printf ("%04d %04d", -5, 5);
-005 0005

as does zsh's printf
% printf '%04d %04d' -5 5
-005 0005

>On Mon, Dec 6, 2010 at 22:04, Mikael Magnusson <mikachu@gmail.com> wrote:

>> I actually realized it's not my fault, it always did that :). (but you
>> still needed setopt braceccl to expand them before the patch).

>Also a bug imo. But as it's been that way, changing it is probably not
>a option, is it?

Well, I don't think a feature only available by an option that does
something completely different can really be said to be reliable, but
I'll let someone else decide, if they even care. I could in any case
limit the nobraceccl case to disallow it.

-- 
Mikael Magnusson

Re: extended braces syntax, {1..32..-03}

[Peter Stephenson]

On Sun, 5 Dec 2010 22:32:01 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> I also just noticed that my code accepts a single - as the number 0,
> should I fix that? ie {-..2} expands to 0 1 2.

I'm not actually worried about this:  it's the sort of edge case where
as long as it does something predictable it doesn't matter much what.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom