Once an exec command fails the next exec command results in a fatal error (when typing exec commands into the Console
window). For example: 

tcl> exec xyzzy
Couldn`t read output file "TMP37.$$$" for command: no such file or directory
tcl> exec dir

and you will get a popup window about the fatal error... 

Other exec bugs on Windows: 

I`m using the recent b2 release with Windows 95 with tclsh75. 

Exec is not redirecting output properly. There seems to be a race condition. 

When I try `exec co -p foo.c > bar.c`, co should write to stdout and tclsh75 should redirect the output to a new file. 

Instead, co -p writes to stdout and it appears on the console window. If I attempt to grab the output by doing: 

set result [exec co -p foo.c > bar.c ]

result is set to "" after the command, even though co writes out the file to stdout. 

Now it gets interesting: If I trace through Win32Pipeline() and stop at the CreateProcess() call, and then step through it closing
the files, the whole thing works the way it should - that is, co writes to stdout, which goes into a file. If after it stops at
CreateProcess() I hit the continue, everything breaks again. So it seems that tclsh needs to create the rpocess and close down the
files before letting the child run. Very odd. 

-Josh Putnam 

- When you exec a command the screen blanks out (system -> DOS?) and then redraws as the command ends. Can this be
stopped? 

- There is a resource leak somewhere in the exec command. If you do "exec dir" several times you will find that the Free Memory
and Free System Resources (as in Program manager/Help/About) decrease each time. 

-Gordon Lack 

Calling exec brings on blank-screen mode 

In article <9603091208.AA08832@diana1.paisley.ac.uk>, Shicheng Tian wrote: 

On my PC, from Windows, I run a tcl script file with the following one line code: 

exec del "c:/rubish.tcl" 

The file `rubish.tcl` DOES get deleted, but the trouble is: 

the PC goes back to the DOS environment (i.e. a black screen!), then it comes back to Windows again. 

My enquiry is: is it possible to run the `exec` command shown as above WITHOUT showing the DOS black screen? 

You can change this behavior by modifying the .PIF file for MS-DOS so that it does not use full-screen mode. 

-Scott Stanton 

Another way to call exec 

It wasn`t obvious to me either how to get native DOS window commands to work and it sometimes hung on me as well. I recently
got it working, however... 

exec cmd.exe >&@stdout <@stdin /c dir

will do the directory command for the current directory. Check out the Windows help for the switches available under cmd.exe. "/c"
tells it to execute the command and then exit. "/k" tells it to execute the command and keep the DOS command interpreter active.
(Note that cmd.exe is the name of the MS-DOS interpreter on Windows NT.) 

-Robert Philpott 

Only Call exec on 32-bit Applications 

Tcl 7.6 and Tk 4.2 seem to have solved the following problem. (Thanks to Colin Stevens.)

Tcl/TK for Win32 is really rotten at doing an exec on DOS mode programs. This includes any of the DOS-like commands of the
Win95 shell! If you use exec with any of the DOS mode commands, the command might execute but control will never be returned
to the WISH shell. 

However, 32 bit programs work just fine with WISH. To see what I mean, try the following command from the WISH console: 

exec notepad 

This command will run the Windows notepad editor and return control to WISH after the notepad program is exited. If you want to
run notepad and return control immediately to WISH just use: 

exec notepad & 

This behavior is identical to the UNIX versions of Tcl/TK. 

So, the moral of the story is: 

Only "exec" 32 bit programs with the Win32 version of Tcl/TK. 

-Dennis R. LaBelle