"John P. Hartmann" wrote: > And Glenn will have to tell me how he wants the output? E.g., a stage per > line with a null line for each pipeline end character?
Oh, the responsibility! Ideally, it should be trivial both to parse everything out and to reassemble a valid pipeline spec. Here's a first thought: ( globaloption value ) streamnum.||*.inout.stream: streamnum.||label.streamID:(localoptions)stage args where: * the parentheses for the global options are always present, * || are the stagesep or endchars, present or implicit, after and before the stage (after first, so that we can just CHOP it off), * the dot and colon are present if and only if there's a label, so we don't have to mess with null labels, and * the parentheses are always present only for stream 0, so that we can CHOP AFTER ) to find the stage name. The redundant sep/end chars are intended to provide a simple way to identify first and last stages. Thinking more about that, I wonder if a pair of flags is better (maybe in the same byte: F0 + first*2 + last). I thought of using a fixed length rather than a delimiter for the stream number, but if there's a maximum it's higher than I can test in the biggest machine I have access to now (998M, ran out of storage somewhere above 4M streams). The dot at least doesn't have to be discarded to yield a valid whole number. This still leaves the task of parsing the local options to the user. It sure would be nice to have them parsed out too, but I'm not seeing a way that leaves the label and stage name easily connected and is still simple to reassemble into a valid pipeline spec. For examination, they could be repeated after the stage: streamnum.||label.streamID:(localoptions)stage args ( localoption value ) but that doesn't provide an easy way to alter them before reassembly. ¬R
