Baffling bug with ${(S)...} or ${...//p/r} and math context

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

I've been fooling with Functions/Prompts/prompt_bart_setup to try to make
the truncation behavior a little better.  prompt_bart_precmd uses the
following expression to compute the width of the first line of the multi-
line prompt:

	${#${(f)${(%%)${(S)PS1//[%]\{*%\}/}}}[1]}
        |  |    |     `-------------------+        Strip %{...%} strings
        |  |    `--------------------------+       Expand the remainder
        |  `--------------------------------+      Split into lines
        `---------------------------------------+  Length of first line

Now here's the strange bit:  If I use that in a math expression (( ... )),
it gives the correct number, and the inequality evaluates correctly:

	((${#${(f)${(%%)${(S)PS1//[%]\{*%\}/}}}[1]} > COLUMNS-2))

However, if I immediately evaluate the same expression again, the answer
is different!  E.g., if I do

	print ${#${(f)${(%%)${(S)PS1//[%]\{*%\}/}}}[1]}
	    ((${#${(f)${(%%)${(S)PS1//[%]\{*%\}/}}}[1]} > COLUMNS-2))
	print ${#${(f)${(%%)${(S)PS1//[%]\{*%\}/}}}[1]}

I'm likely to get

	77
	86

as the output.  If I setopt xtrace, I can see that (( 77 > COLUMNS-2 )) is
being evaluated, and if I leave out the (( ... )) expression 77 is printed
both times, so there's something about math context that messes it up after
the fact.  After that second print, everything is back to normal.

I stepped through the `if (getlen)' block in paramsubst() and found that
in the first `print' and in the (( ... )) expression, the %{...%} strings
are correctly removed by the expansion of ${(S)PS1//[%]\{*%\}/}:

Breakpoint 2, paramsubst (l=0xbffff11c, n=0xbffff110, str=0xbfffefc8, qt=1, 
    ssub=4) at ../../zsh-3.1.6/Src/subst.c:1590
1590            long len = 0;
(gdb) n
1593            if (isarr) {
(gdb) 
1609                if (getlen < 3)
(gdb) 
1610                    len = ztrlen(val);
(gdb) p val
$2 = 0x400e4870 "zagzig+[echo $$]+/usr/src/local/zsh/zsh-3.1.6/Src/Modules+01-04-01+ 9:26PM"
(gdb) p len
$3 = 74
(gdb) c
Continuing.

However, in the second `print' they are not:

Breakpoint 2, paramsubst (l=0xbffff11c, n=0xbffff110, str=0xbfffefc8, qt=1, 
    ssub=4) at ../../zsh-3.1.6/Src/subst.c:1590
1590            long len = 0;
(gdb) n
1593            if (isarr) {
(gdb) n
1609                if (getlen < 3)
(gdb) n
1610                    len = ztrlen(val);
(gdb) p val
$4 = 0x400e4e80 "zagzig+\e[7m[echo $$]\e[27m+/usr/src/local/zsh/zsh-3.1.6/Src/Modules+01-04-01+ 9:26PM"
                        ^^^^^         ^^^^^^

(While running the shell that generated those traces, I'd replaced spaces in
PS1 with `+' to make them visible.)

So it appears that something about either the (S) flag or string matching
with ${...//pat/repl} went awry in the math expression.  Does anybody have
a better clue than I for how to track down this problem?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net