* Baffling bug with ${(S)...} or ${...//p/r} and math context
@ 2001-04-02 4:41 Bart Schaefer
2001-04-11 0:04 ` Peter Stephenson
0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2001-04-02 4:41 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Baffling bug with ${(S)...} or ${...//p/r} and math context
2001-04-02 4:41 Baffling bug with ${(S)...} or ${...//p/r} and math context Bart Schaefer
@ 2001-04-11 0:04 ` Peter Stephenson
2001-04-11 1:17 ` Bart Schaefer
0 siblings, 1 reply; 3+ messages in thread
From: Peter Stephenson @ 2001-04-11 0:04 UTC (permalink / raw)
To: Zsh hackers list
"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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Baffling bug with ${(S)...} or ${...//p/r} and math context
2001-04-11 0:04 ` Peter Stephenson
@ 2001-04-11 1:17 ` Bart Schaefer
0 siblings, 0 replies; 3+ messages in thread
From: Bart Schaefer @ 2001-04-11 1:17 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-04-11 1:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-02 4:41 Baffling bug with ${(S)...} or ${...//p/r} and math context Bart Schaefer
2001-04-11 0:04 ` Peter Stephenson
2001-04-11 1:17 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).