Hello,

I have a simple java program that has a few println statements. I open a
pipe command to this java app. It runs but I can't seem to get any of
its output. I have tried several variations of -blocking/-buffering
options with no avail. Same thing done with a tcl script runs fine.

The open command is:

% set fd [open "|java Test" r]


Any idea to read its output from tcl?

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

Any idea to read its output from tcl?

Can you post a minimal, reproducible example? The following works just fine for me:

% java --version
openjdk 17.0.6 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode)
% package req Tcl
8.6.13
% set ch [open "|java Test" r]
file5
% read -nonewline $ch
Tested!
% close $ch

Assuming the following Java compilation unit: -------------------%<-------------------
class Test {
public static void main(String[] args)
{
System.out.println("Tested!");
}
}
-------------------%<-------------------

Stefan

Hello,

I have a simple java program that has a few println statements. I open a
pipe command to this java app. It runs but I can't seem to get any of
its output. I have tried several variations of -blocking/-buffering
options with no avail. Same thing done with a tcl script runs fine.

The open command is:

% set fd [open "|java Test" r]

Any idea to read its output from tcl?

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

On 6/12/2023 9:49 AM, stefan wrote:

Any idea to read its output from tcl?

Can you post a minimal, reproducible example? The following works just fine for me:

% java --version
openjdk 17.0.6 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode)
% package req Tcl
8.6.13
% set ch [open "|java Test" r]
file5
% read -nonewline $ch
Tested!
% close $ch

Thank you very much for your message. My java code was almost identical
to yours - only the printed message was different. I noticed that you
used "read -nonewline" whereas I had a plain "read". The file
identifiers I get are different from yours too: "file3c6bd18" vs "file5".

It still did not work. So I copied and pasted your exact code and
compiled it. it runs OK from a command shell. When I try it from tcl
(wish and tkcon), this is what I am seeing:

-------------------%<-------------------
set ch [open "|java Test" r]
set data [read -nonewline $ch]
close $ch
puts "GOT IT: $data"
-------------------%<-------------------

This is the output and it is missing "Tested!":

-------------------%<-------------------
% GOT IT:
%
-------------------%<-------------------

This is on Windows, Tcl/Tk 8.6.

% java --version
java 20.0.1 2023-04-18
Java(TM) SE Runtime Environment (build 20.0.1+9-29)
Java HotSpot(TM) 64-Bit Server VM (build 20.0.1+9-29, mixed mode, sharing)

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

saitology9 <[email protected]> wrote:

-------------------%<-------------------
set ch [open "|java Test" r]

Try adding:

fconfigure $ch -buffering line
or
fconfigure $ch -buffering none

here.

set data [read -nonewline $ch]
close $ch
puts "GOT IT: $data"
-------------------%<-------------------

Note the docs for fconfigure, in the -buffering section:

The default is for -buffering to be set to full except for channels
that connect to terminal-like devices; for these channels the initial
setting is line.

As your pipe to the java app is not likely setting itself up as a "terminal-line" device on the Java side, you likely need to adjust
Tcl's buffering default.

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

On 6/12/2023 12:54 PM, Rich wrote:

saitology9 <[email protected]> wrote:

-------------------%<-------------------
set ch [open "|java Test" r]

Try adding:

fconfigure $ch -buffering line
or
fconfigure $ch -buffering none

here.

Thanks, Rich. I have added different buffering and blocking options,
including your suggestions above, alone and together, with no change in
the result.

I see that stefan was using "openjdk" whereas I have plain "jdk".
Perhaps that is the difference? I will try to install it later and see
how that goes.

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

saitology9 <[email protected]> wrote:

On 6/12/2023 12:54 PM, Rich wrote:

saitology9 <[email protected]> wrote:

-------------------%<-------------------
set ch [open "|java Test" r]

Try adding:

fconfigure $ch -buffering line
or
fconfigure $ch -buffering none

here.

Thanks, Rich. I have added different buffering and blocking options, including your suggestions above, alone and together, with no change in
the result.

I see that stefan was using "openjdk" whereas I have plain "jdk".
Perhaps that is the difference? I will try to install it later and see
how that goes.

That would be my next suggestion of where to look, as there are *two*
buffers on a TCP connection. Buffering at the source, and buffering
at the destination.

If your source JDK is doing the equivalent of Tcl's "-buffering full"
for its side of the TCP connect, then it either needs to explicitly
flush the channel to cause transmit (that is until it fills the buffer)
or it needs to close the channel (which causes buffered data to be
sent).

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

On 6/12/2023 1:35 PM, Rich wrote:

saitology9 <[email protected]> wrote:

I see that stefan was using "openjdk" whereas I have plain "jdk".
Perhaps that is the difference? I will try to install it later and see
how that goes.

That would be my next suggestion of where to look, as there are *two*
buffers on a TCP connection. Buffering at the source, and buffering
at the destination.

I installed openjdk (which now redirects to jdk-20.0.1) and guess what?
Both my original program and stefan's version work fine with no
fconfig's needed. That is weird and points to a bug in jdk.


Thank you Rich and stefan.

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

On 12/06/2023 18:54, Rich wrote:

saitology9 <[email protected]> wrote:

-------------------%<-------------------
set ch [open "|java Test" r]

Try adding:

fconfigure $ch -buffering line
or
fconfigure $ch -buffering none

here.

The pipeline is opened in readonly mode. Changing an output option is
then quite unlikely to produce any effect.


Schelte.

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

saitology9 <[email protected]> wrote:

identifiers I get are different from yours too: "file3c6bd18" vs "file5". This is on Windows, Tcl/Tk 8.6.

Something like "file3c6bd18" is typical for windows, "file5" is typical
for non-windows (linux, unix; maybe also macos)

So, essentially it is a Windows-issue, and likely not one of buffering,
or openjdk versus oracle's jdk.

Does it work on command line (cmd.exe) to redirect java's output
to a file? If not, then it might use a specific windows-api to
output its "stdout" directly to the console, ignoring redirection.

There's also a faint chance, that it will do it dependent on
current locale... (e.g. it may use a special api to output utf-8,
which the typical "DOS-box" running cmd.exe otherwise doesn't
display correctly.

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

On 6/13/2023 7:42 AM, Andreas Leitgeb wrote:

So, essentially it is a Windows-issue, and likely not one of buffering,
or openjdk versus oracle's jdk.

Thank you for the info. Here I strongly suspect it was an openjdk vs.
oracle jdk issue as switching to openjdk solved the issue immediately.

Does it work on command line (cmd.exe) to redirect java's output
to a file? If not, then it might use a specific windows-api to
output its "stdout" directly to the console, ignoring redirection.

Yes, it always worked from the command line (cmd.exe), with or without
output redirection.

There's also a faint chance, that it will do it dependent on
current locale... (e.g. it may use a special api to output utf-8,
which the typical "DOS-box" running cmd.exe otherwise doesn't
display correctly.

Scary. I think the dos cmd replacement has a switch that specifies
whether the output is in plain ascii or utf-8 and maybe cmd supports it too.

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

saitology9 <[email protected]> wrote:

On 6/13/2023 7:42 AM, Andreas Leitgeb wrote:

So, essentially it is a Windows-issue, and likely not one of buffering,
or openjdk versus oracle's jdk.

Thank you for the info. Here I strongly suspect it was an openjdk vs.
oracle jdk issue as switching to openjdk solved the issue immediately.

Thanks for the update... I live and learn :-)

Does it work on command line (cmd.exe) to redirect java's output
to a file? If not, then it might use a specific windows-api to
output its "stdout" directly to the console, ignoring redirection.

Yes, it always worked from the command line (cmd.exe), with or without
output redirection.

There's also a faint chance, that it will do it dependent on
current locale... (e.g. it may use a special api to output utf-8,
which the typical "DOS-box" running cmd.exe otherwise doesn't
display correctly.

Scary. I think the dos cmd replacement has a switch that specifies
whether the output is in plain ascii or utf-8 and maybe cmd supports it too.

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