I guess what I was missing is that TOTARGET finding the end-of-response line would terminate the STARMSG. I thought I had to force the gate closed when that happened. -- bc
On Mon, Nov 3, 2014 at 2:05 PM, Glenn Knickerbocker <[email protected]> wrote: > On 11/1/2014 6:11 PM, Bob Cronin wrote: > > Since the whole point of the pipe is to trap the query response and > process > > it (and secondarily to complete as soon as the end of response is seen, > or > > 5 seconds max if not), totarget seemed the logical choice. I'm not sure I > > see how to achieve the same thing in as clear a way in the fashion you > > suggest. > > Just replace TOTARGET with NOT. > > In your pipeline, you're splitting the file once at "End of command > response" with TOTARGET, and then feeding the first line of the second > part to GATE to split it again at the same point. Essentially, you're > using two GATEs to do the same thing. > > Instead, you can just send that one line to the primary of GATE, to stop > reading right there. It doesn't matter which stream the rest of the > file after that would have gone to, because you'll never read it. > > Alternatively, instead of using FANINANY to combine the inputs to the > one GATE, you could use TOTARGET to watch for the end of the response > and GATE for the timeout. But you have to be careful to put them in the > order that you saw worked before, so that the timeout successfully > severs the output of STARMSG: > > > pipe (end ?) strliteral /+5/ > > | delay > > | b: gate > > ? starmsg cp smsg rscs the-query > > | b: > > | c: totarget pick w-4;* == /End of command response/ > > <stuff to process the response> > > And if whatever's downstream severs its input before the end of the > response, you'll see the same problem again, but mitigated by the > successful timeout: EOF won't propagate upstream through TOTARGET, and > you'll wind up waiting for the timeout. > > ¬R >
