From your reply, it looks like I wasn't clear describing what I see as a bug. I was not objecting to .secs being zero, I was saying that .secs on the final execution of a timer should always be zero. Instead, timerbar sees $timer(foo).secs counting down to 1-or-0 on the next-to-last execution, but on the final execution it jumps up to 'delay' or 'delay-less-1' immediately before being eliminated. This should make it more clear:
//echo -a $right($ticks,4) start | timerbar 12 1 echo 6 -ag $!right($ticks,4) timerbar sees foo properties as: secs $!timer(foo).secs reps $!timer(foo).reps | /timerfoo 2 5 echo 4 -ag $!right($ticks,4) timerfoo sees foo properties as: secs $!timer(foo).secs reps $!timer(foo).reps
Reminder that the last 3 digits of the left column show passing of fractional portions of a second. The above displays similar to:
8332 start
* Timer bar activated
* Timer foo activated
9346 timerbar sees foo properties as: secs 4 reps 2
0344 timerbar sees foo properties as: secs 3 reps 2
1343 timerbar sees foo properties as: secs 2 reps 2
2341 timerbar sees foo properties as: secs 1 reps 2
3339 timerbar sees foo properties as: secs 0 reps 2
3355 timerfoo sees foo properties as: secs 4 reps 1
4338 timerbar sees foo properties as: secs 4 reps 1
5336 timerbar sees foo properties as: secs 3 reps 1
6335 timerbar sees foo properties as: secs 2 reps 1
7333 timerbar sees foo properties as: secs 1 reps 1
8347 timerbar sees foo properties as: secs 0 reps 1
8347 timerfoo sees foo properties as: secs 5 reps 0
* Timer foo halted
9345 timerbar sees foo properties as: secs reps
0344 timerbar sees foo properties as: secs reps
* Timer bar halted
The timerbar's final observation of FOO is not always during the same $ticks interval. However even in this example where they were during the same $ticks, timerbar sees foo.secs as 0, but zero ticks later timerfoo sees that same .secs jumping from 0 up to 5 even though foo won't be existing 5 seconds in the future.
It is simply meant to represent the delay until it is next triggered based on the delay value.
If you're saying that .secs returns a value based on the original delay setting regardless whether it's going to execute again (or even if the timer was created with repetitions=1), that isn't consistent when triggering a timer with -e:
//echo -ag $right($ticks,5) start | timerfoo -m 2 999000 echo 4 -ag $!right($ticks,5) foo sees foo: secs $!timer(foo).secs reps $!timer(foo).reps delay $!timer(foo).delay | timerbar -m 1 5000 echo 6 -ag $!right($ticks,5) bar sees foo: secs $!timer(foo).secs reps $!timer(foo).reps delay $!timer(foo).delay | timerfoobar -m 2 5050 timerfoo -e
15043 start
* Timer foo activated
* Timer bar activated
* Timer foobar activated
20066 bar sees foo: secs 993 reps 2 delay 999000
* Timer bar halted
20113 foo sees foo: secs 993 reps 1 delay 999000
25168 foo sees foo: secs 988 reps 0 delay 999000
* Timer foo halted
In this example, both of foo's executions are triggered by -e, and for the final foo execution it doesn't show the original 999 seconds or the actual 0 seconds. Instead timerfoo shows the same externally viewable countdown value seen by timerbar, something it's not doing when -e is not used.
I'm not suggesting that the .secs reported by -e should be changed, just that it's not being consistent with the non -e behavior. It is useful for a script to check .secs to see that it was triggered early by -e, but it doesn't make sense for a normal non -e timer to report 'delay-1' during an execution where it won't exist in the future.
