It is peaceful here without the spam.

I have a black-box textual program for controlling a device.
I thought I'd make some scriptable remote control, but when I tried
using pipe-open there is no communication.
Does this sound familiar to someone who uses Tcl on Windows more than
I do?

More specifics...

set pfh [open "C:/Users/$tcl_platform(user)/blah/foobar.exe" r+]
fconfigure $pfh -blocking 0 -translation binary

The task manager shows the "foobar" task running.
(The task manager shows it running even after [close $pfh].)

I used [read $pfh] or [read $pfh 1] but both returned no characters.
I sent input to it using puts -nonewline $pfh "\r"; flush $pfh
but no responses were seen by read.
Fileevent readable never triggers.

This program does seem to run in the cmd terminal when you type it's
path, but if you click on it in explorer, it opens a cmd terminal to run
in.

Does it sound that pipe-open is bound to fail?
Should I try expect (but I don't think expect exists for Windows now)?
Maybe twapi can interface, but I've never used twapi and don't know.

Thanks for any insight I can get from more experienced denizens.

--
Donald Arseneau asnd@triumf.ca

On 4/29/2024 10:11 PM, Donald Arseneau wrote:

> More specifics...
>
> set pfh [open "C:/Users/$tcl_platform(user)/blah/foobar.exe" r+]
> fconfigure $pfh -blocking 0 -translation binary
>
Is that the actual code? Don't you need a pipe char | before the file name?

-e

Donald Arseneau <asnd@triumf.ca> posted:

> It is peaceful here without the spam.
>
> I have a black-box textual program for controlling a device.
> I thought I'd make some scriptable remote control, but when I tried
> using pipe-open there is no communication.
> Does this sound familiar to someone who uses Tcl on Windows more than
> I do?
>
I suspect TWAPI is your best bet, specifically the functions for sending
keyboard and mouse input - https://twapi.magicsplat.com/v4.7/input.html
My rather crude https://wiki.tcl-lang.org/page/AdvertSkipper+for+YouTube
uses this stuff.

If you need to read output from the controlled program, I would look at
sending the keystrokes to copy the output to the clipboard, and then use
the Tk clipboard command to read that.

--
Colin Macleod.

* Donald Arseneau <asnd@triumf.ca>
| It is peaceful here without the spam.

:-)

| More specifics...
>
| set pfh [open "C:/Users/$tcl_platform(user)/blah/foobar.exe" r+]

et99 already pointed out the missing "|" at the start of the command,
but since you say the task is running, I assume this is just a
copy/paste error.

| I used [read $pfh] or [read $pfh 1] but both returned no characters.
| I sent input to it using puts -nonewline $pfh "\r"; flush $pfh
| but no responses were seen by read.
| Fileevent readable never triggers.

It all depends whether the foobar.exe actually uses stdin/stdout for
communication, and whether it flushes its stdout when it writes
something. Does the program generate output when it start which you can
redirect to a file? I.e. running

foobar > _tmp.txt

in a cmd shell, does that create contents in that file?

| Does it sound that pipe-open is bound to fail?

In general: no. I use pipe-open on Windows on a regular basis, though
mostly between my own (TCL-based-)programs, which set stdout to line
buffering, so each 'puts' actually flushes the output, so the other
process can read it.

HTH
R'

et99 <et99@rocketship1.me> writes:

> On 4/29/2024 10:11 PM, Donald Arseneau wrote:
>
>> More specifics...
>>
>> set pfh [open "C:/Users/$tcl_platform(user)/blah/foobar.exe" r+]
>> fconfigure $pfh -blocking 0 -translation binary
>>
> Is that the actual code? Don't you need a pipe char | before the file name?

ACK! Typo In the message, but not in the test.

So clumsy.

--
Donald Arseneau asnd@triumf.ca

Ralf Fassel <ralfixx@gmx.de> writes:

> | set pfh [open "C:/Users/$tcl_platform(user)/blah/foobar.exe" r+]
>
> et99 already pointed out the missing "|" at the start of the command,
> but since you say the task is running, I assume this is just a
> copy/paste error.

I typed it in the message without pasting (not blah/foobar).

> | I used [read $pfh] or [read $pfh 1] but both returned no characters.
> | I sent input to it using puts -nonewline $pfh "\r"; flush $pfh
> | but no responses were seen by read.
> | Fileevent readable never triggers.
>
> It all depends whether the foobar.exe actually uses stdin/stdout for
> communication, and whether it flushes its stdout when it writes
> something. Does the program generate output when it start which you can
> redirect to a file? I.e. running
>
> foobar > _tmp.txt
>
> in a cmd shell, does that create contents in that file?

Great test! Yes it does populate the file, including the echoed
input commands and the output. The output file is created immediately,
but does not get any text until the program exits (which I did by typing
q<CR>).
>
> | Does it sound that pipe-open is bound to fail?
>
> In general: no. I use pipe-open on Windows on a regular basis, though
> mostly between my own (TCL-based-)programs, which set stdout to line
> buffering, so each 'puts' actually flushes the output, so the other
> process can read it.

I wonder if I can start that program in a way that defeats buffering...

--
Donald Arseneau asnd@triumf.ca

Donald Arseneau <asnd@triumf.ca> writes:

> I wonder if I can start that program in a way that defeats buffering...

I should add that I tried
fconfigure $pfh -blocking 0 -buffering none -translation binary
and lots of
flush $pfh
already.

--
Donald Arseneau asnd@triumf.ca

On 4/30/2024 3:11 PM, Donald Arseneau wrote:
> Donald Arseneau <asnd@triumf.ca> writes:
>
>> I wonder if I can start that program in a way that defeats buffering...
>
> I should add that I tried
> fconfigure $pfh -blocking 0 -buffering none -translation binary
> and lots of
> flush $pfh
> already.
>

Since you have a "black-box" executable, what about redirecting both it's input/output and then use named pipes for both, to see what's going on.

I got chatGPT to write some code in C, python, and Tcl for creating and then reading/writing to named pipes.

From a command line you can then do: foobar.exe < \\.\pipe\MyNamedPipe

to see if foobar.exe will cooperate on reading from a pipe. You can also then send it stuff, and multiple readers will each see all the data (like tee), or so chatGPT tells me.

FWIW, chatGPT seemed pretty knowledgeable about named pipes and wrote some decent Tcl code :)

Here's what it gave me as a test program to write to the pipe:

proc write_to_named_pipe {pipe_tail data} {
set pipeName "\\\\.\\pipe\\$pipe_tail"
set pipe [open $pipeName w]
puts $pipe $data
close $pipe
}

# Check if two command-line arguments are provided
if {[llength $argv] == 2} {
# Get the command-line arguments
set data [lindex $argv 0]
set pipeTail [lindex $argv 1]

# Write the data to the named pipe
write_to_named_pipe $pipeTail $data
} else {
puts "Usage: tclsh script_name.tcl data pipe_tail"
}

-e

Donald Arseneau <asnd@triumf.ca> wrote:
> Ralf Fassel <ralfixx@gmx.de> writes:
>> It all depends whether the foobar.exe actually uses stdin/stdout for
>> communication, and whether it flushes its stdout when it writes
>> something. Does the program generate output when it start which you can
>> redirect to a file? I.e. running
>> foobar > _tmp.txt
>> in a cmd shell, does that create contents in that file?
>
> Great test! Yes it does populate the file, including the echoed
> input commands and the output. The output file is created immediately,
> but does not get any text until the program exits (which I did by typing
> q<CR>).
>
> I wonder if I can start that program in a way that defeats buffering...

I think, that is just the gap for "expect", and I think such exists, or
at least once existed for Windows. Maybe some aged "expect 4 windows"
found on the 'net might be enough for this task, if it is based on some
8.3, 8.4 or 8.5 tcl...