Arithmetic expression (bug?)

Arithmetic expression (bug?)

[Phil Pennock]

Okay, is a base-ten number, in the right context, an arithmetic
expression?  The manual-page bit dealing with Arithmetic Evaluation
(zshmisc(1)) doesn't explicitly say so, but it seems obvious that it
should.

So, given this:
-----------------------------< cut here >-------------------------------
foo=alpha
print -- ${(l<$[10]><x>)foo}
print -- ${(l<10><x>)foo}
-----------------------------< cut here >-------------------------------
why does the third line produce:
./testfile: error in flags [3]
?

According to zshexpn(1), the Parameter Expansion Flag 'l' expects the
first field to be 'expr', the width of the output string.  This would
appear to be treated as a numerical value ;^) and I expected a value of
'10' for the field to work.

Is the bug in me or in zsh (3.1.5 unpatched)?

Thanks.
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* r y?

Re: Arithmetic expression (bug?)

[Bernd Eggink]

Phil Pennock wrote:
> 
> Okay, is a base-ten number, in the right context, an arithmetic
> expression?  The manual-page bit dealing with Arithmetic Evaluation
> (zshmisc(1)) doesn't explicitly say so, but it seems obvious that it
> should.
> 
> So, given this:
> -----------------------------< cut here >-------------------------------
> foo=alpha
> print -- ${(l<$[10]><x>)foo}
> print -- ${(l<10><x>)foo}
> -----------------------------< cut here >-------------------------------
> why does the third line produce:
> ./testfile: error in flags [3]
> ?

I can't reproduce this. For me it works perfectly. I get the expected

xxxxxalpha

Hm, are you sure the right shell is started with your script? 

Bernd

--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html

Re: Arithmetic expression (bug?)

[Phil Pennock]

Typing away merrily, Bernd Eggink produced the immortal words:
> > -----------------------------< cut here >-------------------------------
> > foo=alpha
> > print -- ${(l<$[10]><x>)foo}
> > print -- ${(l<10><x>)foo}
> > -----------------------------< cut here >-------------------------------
> > why does the third line produce:
> > ./testfile: error in flags [3]
> > ?
> 
> I can't reproduce this. For me it works perfectly. I get the expected
> 
> xxxxxalpha
> 
> Hm, are you sure the right shell is started with your script? 

Yes.  I used ``zsh -f'' and this is 3.1.5, with, as I said, no patches.

Extra detail:
 OS:   SuSE Linux (2.0.34+patches kernel)
 Arch: x86 PC (AMD K6)
 Configure options: --enable-dynamic
 Misc: Defaults used for all stages of install, except for enabling
       modules.
 Note: I know I'm missing something ...

Note that there are two print statements.  The first works, the second
doesn't.

And I know, I probably shouldn't use a 3.1.x as a default shell, but
I've come to rely on things like widgets.  If for nothing else, then to
have an invocation of setfont(8) bound to a func-key to restore sanity
after X11 horribly hexes things.  And having cdpause(1) bound is one of
those things you wonder how you ever did without.

I'm on the list now, BTW, so there's no need to CC.  But thanks anyway.
:^)
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* r y?

Re: Arithmetic expression (bug?)

[Bart Schaefer]

Catching up on some more old stuff:

On Nov 5,  1:40am, Phil Pennock wrote:
} Subject: Re: Arithmetic expression (bug?)
}
} Typing away merrily, Bernd Eggink produced the immortal words:
} > > -----------------------------< cut here >-------------------------------
} > > foo=alpha
} > > print -- ${(l<$[10]><x>)foo}
} > > print -- ${(l<10><x>)foo}
} > > -----------------------------< cut here >-------------------------------
} > > why does the third line produce:
} > > ./testfile: error in flags [3]
} > > ?
} > 
} > I can't reproduce this.

I *can* reproduce this.  I can reproduce it in 3.0.5, too.

The problem is with the parse:

    l<$[10]><x> parses as
    	'l' '<' String Inbrack '1' '0' Outbrack '>' '<' 'x' '>'

    l<10><x> parses as
    	'l' Inang '1' '0' Outang '<' 'x' '>'

Now because (Inang != '<') the error is reported when looking at the <x>
after correctly scanning the <10>.

I'm not fluent enough with the parser to understand why that happens, or
whether the fix is to treat Inang, Inpar, etc. as equal to '<', '(', etc.
in the substitution code, or to actually modify the parser.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Arithmetic expression (bug?)

[Bart Schaefer]

On Nov 4,  9:34pm, Phil Pennock wrote:
} Subject: Arithmetic expression (bug?)
}
} -----------------------------< cut here >-------------------------------
} foo=alpha
} print -- ${(l<$[10]><x>)foo}
} print -- ${(l<10><x>)foo}
} -----------------------------< cut here >-------------------------------
} why does the third line produce:
} ./testfile: error in flags [3]
} ?

Having just said I wasn't sure how to fix this, here's a patch that takes
care of it.  I'm still not sure it's the *best* patch for it ....

Index: Src/subst.c
===================================================================
--- subst.c	1998/11/12 09:21:35	1.2
+++ subst.c	1998/11/15 22:27:52
@@ -743,6 +743,7 @@
 	    long num;
 	    int escapes = 0;
 	    int klen;
+#define UNTOK(C)  (itok(C) ? ztokens[(C) - Pound] : (C))
 #define UNTOK_AND_ESCAPE(X) {\
 		untokenize(X = dupstring(s + 1));\
 		if (escapes) {\
@@ -856,7 +857,7 @@
 			prenum = num;
 		    else
 			postnum = num;
-		    if (s[1] != sav)
+		    if (UNTOK(s[1]) != UNTOK(sav))
 			break;
 		    t = get_strarg(++s);
 		    if (!*t)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

PATCH: 3.1.5 and 3.0.5: ${(l<e><s1><s2>)param} (was Re: Arithmetic expression (bug?))

[Bart Schaefer]

On Nov 15,  2:46pm, Bart Schaefer wrote:
} Subject: Re: Arithmetic expression (bug?)
}
} Having just said I wasn't sure how to fix this, here's a patch that takes
} care of it.

That patch didn't go far enough; it misses the case where two strings are
passed to (l...) or (r...).  Use this one instead (and this time I did
remember to put the word PATCH in the subject).

Index: Src/subst.c
===================================================================
--- subst.c	1998/11/12 09:21:35	1.2
+++ subst.c	1998/11/15 22:27:52
@@ -743,6 +743,7 @@
 	    long num;
 	    int escapes = 0;
 	    int klen;
+#define UNTOK(C)  (itok(C) ? ztokens[(C) - Pound] : (C))
 #define UNTOK_AND_ESCAPE(X) {\
 		untokenize(X = dupstring(s + 1));\
 		if (escapes) {\
@@ -856,7 +857,7 @@
 			prenum = num;
 		    else
 			postnum = num;
-		    if (s[1] != sav)
+		    if (UNTOK(s[1]) != UNTOK(sav))
 			break;
 		    t = get_strarg(++s);
 		    if (!*t)
@@ -871,7 +871,7 @@
 		    *t = sav;
 		    sav = *s;
 		    s = t + 1;
-		    if (*s != sav) {
+		    if (UNTOK(*s) != UNTOK(sav)) {
 			s--;
 			break;
 		    }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

More about ${(l:e::s1::s2:)param}

[Bart Schaefer]

The info says:

`l:'EXPR`::'STRING1`::'STRING2`:'
     Pad the resulting words on the left.  Each word will be truncated
     if required and placed in a field EXPR characters wide.  The space
     to the left will be filled with STRING1 (concatenated as often as
     needed) or spaces if STRING1 is not given.  If both STRING1 and
     STRING2 are given, this string will be placed exactly once
     directly to the left of the resulting word.

`r:'EXPR`::'STRING1`::'STRING2`:'
     As `l', but pad the words on the right.

Apparently "the resulting word" is "the word before padding with STRING1":

zagzig<1> foo=77
zagzig<2> print -- ${(l:5::0::x:)foo}
00x77
zagzig<3> print -- ${(r:5::0::x:)foo} 
77x00

The doc phrasing led me to expect x00077 and 77000x.  What needs fixing,
the doc or the code?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com