When using
/signal -n bvars present in the caller's scope can be manipulated within the signal event. The changes made within the signal event alter the bvar present in the outer scope. But the reverse is
NOT true. BVars created within a signal event do no propagate into the caller's scope. This is, at the least, unexpected as bvars are considered globally scoped.
Example code:
alias example {
; bvar not created prior to signal call;
; Should result in the bvar being set to xyz
signal -n example
echo -a Post-Signal: $bvar(&example, 0)
; bvar created prior to signal call
bset -t &example 1 abc
signal -n example
echo -a Post-Signal: $bvar(&example, 0)
}
on *:SIGNAL:example:{
bset -t &example -1 xyz
echo -s In Signal: $bvar(&example, 1-).text
}I stumbled upon this working on an HTTP client what allows for custom headers to be specified from signal events. Figured I could store the headers in a bvar, and then access that bvar after the signal event to add headers had finished:
.signal -n AddHeaders!Example
if ($bvar(&customheaders)) {
; append to HTTP request
}Instead I have to create the bvar with arbitary data first, then remove that data after the call:
bset &customheaders 1 0
if ($bvar(&customheaders, 0) > 1) {
bcopy -c &customheaders 1 &customheaders 2 -1
; append to HTTP request
}I believe this is a case of the bvars being unset prematurely after the /signal has finished but before execution is returned to the caller.
--
After further testing, I'm
positive it is 'execution cleanup' after the signal events finish but before execution is returned to the caller, as variables exhibit the same behavior:
alias example {
; %example is $null after the signal
signal -n example
echo -s > %example
; %example is 'value' after the signal
set -u0 %example value
signal -n example
echo -s > %example
}
on *:SIGNAL:example:{
set -ku0 %example value
}
