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. The %stdin device does not do that; it will read it immediately. How to fix so that it can be done by a pipe called by the PostScript program, also, instead of only stdin?

--
Don't laugh at the moon when it is day time in France.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Reiser <[email protected]> wrote:

Sounds like the writing PostScript process should use 'flush' or '(%stdout%) flushfile'
to force the few bytes into the file from the output buffer.

The writing process is not a PostScript program, but a C program; the PostScript program is reading the output from it. (Note that it does
not do this with standard input (even if it is connected to the same
C program); it only does this with a pipe. (The C program does flush
the output. The PostScript program is doing input; it does flush stdout
but that doesn't affect the %pipe% at all.)

--
Don't laugh at the moon when it is day time in France.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Don't laugh at the moon when it is day time in France.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, January 11, 2022 at 5:57:41 PM UTC-6, [email protected]d wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

luser droog <[email protected]> wrote:

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.

That is not related, and does not help. (I am not sure how else to explain.)

--
Don't laugh at the moon when it is day time in France.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, January 20, 2022 at 3:14:19 AM UTC-6, [email protected]d wrote:

luser droog <[email protected]> wrote:

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.

That is not related, and does not help. (I am not sure how else to explain.) --
Don't laugh at the moon when it is day time in France.

Sorry about that. I've read the thread again and done some thinking.
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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, January 20, 2022 at 6:56:44 PM UTC-6, luser droog wrote:

On Thursday, January 20, 2022 at 3:14:19 AM UTC-6, [email protected]d wrote:

luser droog <[email protected]> wrote:

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.

That is not related, and does not help. (I am not sure how else to explain.)
--
Don't laugh at the moon when it is day time in France.

Sorry about that. I've read the thread again and done some thinking.
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."

Making sure I'm clear. The following is all guess-work on my part. If any of my guesses are wrong, my conclusions are probably wrong.

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.

I don't know this for a fact.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)