>> > Reason is that traps are not recursive, IIRC: Traps are not
>> > handled while another trap is active (this seems to be missing in
>> > the info file).
>
> But they are handled sequentially when a `.sp' passes more than one in a
> single bound.
Yes.
>> > In other words, while your first trap is active, it moves down
>> > one line, which passes some traps without triggering them.
>>
>> That bit of information is missing from the manual
>
> And from CSTR 54. Werner, are you sure about that? I don't recall
> hearing it before.
No, I'm not sure, but I don't have a different explanation without
debugging this (for which I don't have time, sorry).
> Going back to Dave's supplied test, I get two distinct sets of
> output. [...]
>
> Appending ` \n(nl' to each `.tm' line and repeated runs, commenting
> various `.wh' out, and then marking up what's present in the above
> output, and what's a duplicate, gives
>
> ps
> trap 1 156000 present
> trap 2 168000 present
> trap 3 168000 same as 2
> trap 4 180000 present
> trap 5 180000 same as 4
> trap 6 192000 present
BTW, an exact list of trap positions can be printed using the `.ptr'
request:
trap1 151200
trap2 158400
trap3 165600
trap4 172800
trap5 180000
trap6 187200
Werner
