From Newsgroup: comp.lang.tcl

This works and it opens wordpad on Windows:

% package req Tk
% set f [tk_getOpenFile]
C:/Program Files (x86)/Windows NT/Accessories/wordpad.exe
% exec $f


But if I choose a Tcl script in the file selection dialog, then exec
throws an error:

% exec $f
couldn't execute "C:\blah\blah\blah.tcl": no such file or directory

Weird thing is that exec seems to have changed forward slashes to
backward slashes during this process. It doesn't matter if I add a
shebang line at the top the Tcl script files. It complains either way.
Putting the file $f in a list doesn't change the outcome.

Why can't exec run Tcl scripts?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 06.03.2026 um 18:11 schrieb saito:

Why can't exec run Tcl scripts?

Probably because the skript is not an executable?
It will work if you execute wish.exe along with the script name as a
command line argument.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <[email protected]> wrote:

This works and it opens wordpad on Windows:

% package req Tk
% set f [tk_getOpenFile]
C:/Program Files (x86)/Windows NT/Accessories/wordpad.exe
% exec $f

But if I choose a Tcl script in the file selection dialog, then exec
throws an error:

% exec $f
couldn't execute "C:\blah\blah\blah.tcl": no such file or directory

Weird thing is that exec seems to have changed forward slashes to
backward slashes during this process. It doesn't matter if I add a
shebang line at the top the Tcl script files. It complains either way. Putting the file $f in a list doesn't change the outcome.

Why can't exec run Tcl scripts?

Because winblows is not a Linux/Unix system. exec passes whatever you
give it off to the OS, and if the OS does not know how to "run" a tcl
script (and winblows does not unless you have configured it to know
how) then the OS cannot run the script.

Note that a 'shebang' line is for Linux/Unix systems, where a script
can be made into a first class executable and the OS will launch it
just like any other executable. The closest you get on winblows is
creating a shortcut with the proper launch command line in the
shortcut, and then running 'exec' on the shortcut.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 3/6/2026 1:23 PM, Rich wrote:

Because winblows is not a Linux/Unix system. exec passes whatever you
give it off to the OS, and if the OS does not know how to "run" a tcl
script (and winblows does not unless you have configured it to know
how) then the OS cannot run the script.

The way it is in Windows is you can register file extensions with
certain applications so when you double click on them, they run. In this
case, it is configured like that. As you said, it is winblows.


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 3/6/2026 12:26 PM, meshparts wrote:

Am 06.03.2026 um 18:11 schrieb saito:

Why can't exec run Tcl scripts?

Probably because the skript is not an executable?
It will work if you execute wish.exe along with the script name as a
command line argument.

Yes, this will work. Thanks for the rpely.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <[email protected]> wrote:

On 3/6/2026 1:23 PM, Rich wrote:

Because winblows is not a Linux/Unix system. exec passes whatever you
give it off to the OS, and if the OS does not know how to "run" a tcl
script (and winblows does not unless you have configured it to know
how) then the OS cannot run the script.

The way it is in Windows is you can register file extensions with
certain applications so when you double click on them, they run. In this case, it is configured like that. As you said, it is winblows.

Then you may need to make use of 'auto_execok' to launch the tcl
script.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 3/6/2026 2:40 PM, Rich wrote:

Then you may need to make use of 'auto_execok' to launch the tcl
script.

I will have to try that! I stumbled into a solution earlier which is
the same as that suggested by meshparts.

I wonder if you have an insight into this though:

I have a socket in a script. I would like to pass it to a separate
script I am exec'ing which will write to it and then close it when it is
done.

I am using this syntax:

exec $script $arg1 $arg2 >@ $sock

This command sets up the script so that the socket is now its stdout.
This works OK for files: If I open a file, and use the file handle
instead of a socket in the above statement, everything works fine. The script's output ends up in the file.

But for sockets, it doesn't work for some reason. It seems that the
script is not able to write to the socket.

Perhaps this is not possible, I am not sure.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 3/6/2026 11:40 AM, Rich wrote:

saito <[email protected]> wrote:

On 3/6/2026 1:23 PM, Rich wrote:

Because winblows is not a Linux/Unix system. exec passes whatever you
give it off to the OS, and if the OS does not know how to "run" a tcl
script (and winblows does not unless you have configured it to know
how) then the OS cannot run the script.

The way it is in Windows is you can register file extensions with
certain applications so when you double click on them, they run. In this
case, it is configured like that. As you said, it is winblows.

Then you may need to make use of 'auto_execok' to launch the tcl
script.

I don't think that will work. If the arg is say, file.tcl then [auto_execok file.tcl] returns simply file.tcl.

This, however, does work for me, using the magicsplat distro:

exec C:/Windows/System32/cmd.exe /c "a:/blah.tclapp"

What occurs is that first cmd.exe is run as above but with the program cmd.exe spec changed to use \ instead of / but the rest goes in as shown.

Then cmd.exe looks up how to run a .tclapp file and launches magicsplat's tclsh:

"....fullpathto....\bin\tclsh.exe" "A:\blah.tclapp"

This I determined by using procmon.exe as described in the other thread started by meshparts.

I'm not sure if magicsplat also sets up .tcl, but it does set up .tkapp and .tclapp to run wish or tclsh respectively.

The above, if changed to blah.tcl will launch a starpak I've built that includes all my debugging tools and other startup scripts. This occurs because I setup the .tcl extension myself.


-e



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <[email protected]> wrote:

On 3/6/2026 2:40 PM, Rich wrote:

Then you may need to make use of 'auto_execok' to launch the tcl
script.

I will have to try that! I stumbled into a solution earlier which is
the same as that suggested by meshparts.

I wonder if you have an insight into this though:

I have a socket in a script. I would like to pass it to a separate
script I am exec'ing which will write to it and then close it when it is done.

I am using this syntax:

exec $script $arg1 $arg2 >@ $sock

This command sets up the script so that the socket is now its stdout.
This works OK for files: If I open a file, and use the file handle
instead of a socket in the above statement, everything works fine. The script's output ends up in the file.

But for sockets, it doesn't work for some reason. It seems that the
script is not able to write to the socket.

Perhaps this is not possible, I am not sure.

Not sure why that does not work, unless the underlying difference
between sockets and actual on-disk files is why.
--- Synchronet 3.21d-Linux NewsLink 1.2