>I've come across a rather strange bug while trying to use a variable inside
>a $"".
>
>alias buggy {
> timer 1 set status_user22 foo
> local foo Enter something:
> local bar $"$foo"
>}
>
>alias notbuggy {
> timer 1 set status_user22 foo
> local foo $"Enter something:"
>}
>
>(STATUS_USER22 is not displayed on any of my status bars, incidentally.)
>
>In /buggy, when the timer expires, the input prompt vanishes until one of
>refresh_{inputline,screen,status} happens. In /notbuggy, it doesn't.
This is a bug, but it's not really a bug; it's hard to describe just whose
bug it is, though...
I can say with absolute certainty the reasons for the behavior you're
seeing. I can also say that it's more or less intentional that it behaves
this way, but conceed that it kind of seems confusing when you run into
cases like this where it doesn't do what you think it should do.
$".." expansion is done "inline" and "at expansion time". A line of text
in ircII always is considered literal text until something "expands" it.
The ircII expander sometimes "protects" the insides of certain types of
punctuation marks, like (...), [...], {....}. However, it also protects
the inside of double-quotes, because whenever ircII sees a dollar sign and
a double-quote, it immediately looks for the trailing double-quote and then
takes the inside of the double quotes *as literal text* and passes it to
the input-prompt-handler. It is important to understand that the inside of
$"..." is not "doubly-expanded"; it is left as-is.
The input prompt handler always has accepted expandoes, and has always
expanded expandos. This is what lets you do things like
/set input_prompt $T>
and get the current target in your input prompt. It is essential that the
input prompt handler expand expandos.
But it would be a dangerous security hazard if $"..." expanded the inside
because the input prompt handler would expand it again -- double expansion
is the boogy man of backdoors. So it's essential that $"..." not expand.
Now it comes down to just what variable you mean when you do input line
handling. Part of setting the status bar format variables is that all of
the status lines and the input lines are redrawn. In your example, this
is done inside of a /timer. A /timer is an "atomic scope" meaning that it
gets its own local variable stack and its own local variables, and local
variables outside of its stack are not visible.
When you execute your timer, you cause the input line to be redrawn, but
the $foo you thought you were using was /local to the /buggy alias, and
IT IS NOT IN SCOPE in the /timer -- thus, it expands to the empty string.
When the timer exits, it goes back to /buggy, where $foo is in scope.
When you redraw the screen, epic is still sitting in /buggy, and now $foo
is in scope; the prompt "re-appears" again.
As you noticed, if you don't use local variables in your input prompt, this
problem doesn't occur. The only suggestion I can offer is don't use local
variables in input prompts -- bad things can happen to it.
It's not reasonable to change the input prompt handler, and it's a security
hazard to change $"...", so the only thing that has to change is the script.
Sorry. :/
Jeremy
_______________________________________________
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list
