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.

> 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.

John Reiser <vendor@BitWagon.com> 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.

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.

On Tuesday, January 11, 2022 at 5:57:41 PM UTC-6, ne...@zzo38computer.org.invalid 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.

luser droog <luser.droog@gmail.com> 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.

On Thursday, January 20, 2022 at 3:14:19 AM UTC-6, ne...@zzo38computer.org.invalid wrote:
> luser droog <luser...@gmail.com> 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.

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, ne...@zzo38computer.org.invalid wrote:
> > luser droog <luser...@gmail.com> 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.