Hello,

I'm trying to read from a command pipelined channel but the channel closes before I've read the wanted output. I'm trying to read the boundingbox parameters (see below) but the channel closes at the very same line, before the line is properly read.

The wanted data could be extracted by using the exceptional return but I'm curious as to why this behavior appears and what could be a proper way to perform this read.

Any ideas and/or comments are much appreciated.

Here is the code I'm running:
Output:

Here is the output when the GS script is run in the command promt:

Thanks

Peter

Are you sure it's the pipeline that's misbehaving and not Ghostscript? I don't know how the arguments work for GS so I would try a simpler pipeline and work up from there. Also, "while true" is going to go berserk if you ever get stuck in "else".

_________________
Bob Rashkin

Thanks for the reply,

Hmm, it seems like GS is returning a '-1' right after the line stating "Page 1" causing the pipeline to close.

Otherwise I believe the GS arguments to be ok. And I hear you regarding while{true}-loop. It's not pretty and was merely used for debugging. It will be adjusted as soon as this start to work .

If I'm not mistaking, the pipeline automatically closes when a '-1' is read (please correct me if I'm wrong).

So if my thesis is correct and a -1 is returned after "Page 1" causing the pipeline to automatically close: Is there a way to get tcl to disregard the first '-1' and keep on reading until the second '-1'?

I know nothing of GS. As I suggested above, I'd work out the kinks in the process pipeline with something simpler. Also, a lot of these OS-type deals in Tcl were really designed for Unix and I don't trust that they always work well in Windows (just my own paranoia).

Anyway, you're telling it to close if it reads <0 so you could just as well put in a counter and complicate your condition:

That said, I think GS sending -1 is ominous, but I don't know anything about GS as I said.

_________________
Bob Rashkin