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

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

[Bart Schaefer]

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   

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

[Peter Stephenson]

"Bart Schaefer" wrote:
> 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.

Hmm, it wouldn't be something to do with the fact that the length of the
output, even excluding %{...%}'s, varies with the status of the previous
command, by any chance?

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

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

[Bart Schaefer]

On Apr 11,  1:04am, Peter Stephenson wrote:
} Subject: Re: Baffling bug with ${(S)...} or ${...//p/r} and math context
}
} Hmm, it wouldn't be something to do with the fact that the length of the
} output, even excluding %{...%}'s, varies with the status of the previous
} command, by any chance?

(Sound of hand smacking forehead)

The prompt system internally knows that %U/%u %S/%s %B/%b don't take up any
space, but they don't disappear from ${(%%)...} expansions.  There's a
conditional on exit status that includes a %S/%s pair.

Now I just have to figure out what to do about it ...

-- 
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