If you use %pipe% with a program that writes only a few bytes of output and then is not finished yet, then the PostScript code will not be able to read it immediately.
Sounds like the writing PostScript process should use 'flush' or '(%stdout%) flushfile'
to force the few bytes into the file from the output buffer.
Perhaps I should provide a example:
(%pipe%echo -n 1; sleep 1; echo -n 2; xkbbell; sleep 1; echo -n 3)
(r) file read pstack flush
The expectation should be that the first byte (49) should be readable
right away, and then after one second is a bell and the second byte is readable, etc.
That isn't what it does; instead it executes (including the bell after
one second), but only after two seconds (when the program specified in
the pipe is terminated) will it be readable.
It works as expected if it is read from %stdin (piping it to Ghostscript, given suitable PostScript code) instead of %pipe%, though.
I may not completely follow what you're ultimately trying to do. But just in case you haven't heard of it, there's a little known unix tool called expect(1)
that was designed to help with these sort of pipe/flushing issues. It was written by the same guy that wrote Tcl/tk.
luser droog <luser...@gmail.com> wrote:
I may not completely follow what you're ultimately trying to do. But just inThat is not related, and does not help. (I am not sure how else to explain.) --
case you haven't heard of it, there's a little known unix tool called expect(1)
that was designed to help with these sort of pipe/flushing issues. It was written by the same guy that wrote Tcl/tk.
Don't laugh at the moon when it is day time in France.
On Thursday, January 20, 2022 at 3:14:19 AM UTC-6, ne...@zzo38computer.org.invalid wrote:
luser droog <luser...@gmail.com> wrote:Sorry about that. I've read the thread again and done some thinking.
I may not completely follow what you're ultimately trying to do. But just inThat is not related, and does not help. (I am not sure how else to explain.)
case you haven't heard of it, there's a little known unix tool called expect(1)
that was designed to help with these sort of pipe/flushing issues. It was
written by the same guy that wrote Tcl/tk.
--
Don't laugh at the moon when it is day time in France.
But I fear the answer is just as you've discovered. According to https://www.ghostscript.com/doc/current/Language.htm#File
" Ghostscript also supports the following IODevice in addition to a subset of those defined in the Adobe documentation:
"%pipe%command, which opens a pipe on the given command. This is
supported only on operating systems that provide popen (primarily Unix systems, and not all of those)."
Then (my local) `man popen` says:
" Use popen to create a stream to a child process executing a command string *s as
processed by /bin/sh on your system. The argument mode must start with either `r',
where the stream reads from the child's stdout, or `w', where the stream writes to
the child's stdin. As an extension, mode may also contain `e' to set the close-on-exec bit of the parent's file descriptor. The stream created by popen must
be closed by pclose to avoid resource leaks."
So, I think ghostscript is using the minimal guarantees that POSIX gives
for popen(1) which is that you can read OR write from it. Ghoscript is presumably adding a "> /tmp/$$pipe-output" to your command line,
creating a writable pipe, and then giving you a read handle to that temp file later on. That would explain the blocking that you're experiencing.
Bad news is I don't see any way to change it except by changing the C code that
implements the %pipe% device.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 63 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 492946:27:13 |
| Calls: | 840 |
| Files: | 1,300 |
| D/L today: |
5 files (1,241K bytes) |
| Messages: | 260,694 |