Merge tip of core-8-6-branchbug_16828b3744

1 files changed, 5 insertions, 70 deletions

diff --git a/doc/exec.n b/doc/exec.n
index 5072d61..9d58d90 100644
--- a/doc/exec.n
+++ b/doc/exec.n
@@ -5,9 +5,9 @@
 '\"
 '\" See the file "license.terms" for information on usage and redistribution
 '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
-'\" 
-.so man.macros
+'\"
 .TH exec n 8.5 Tcl "Tcl Built-In Commands"
+.so man.macros
 .BS
 '\" Note:  do not modify the .SH NAME line immediately below!
 .SH NAME
@@ -220,7 +220,7 @@ discarded.
 The Tk console text widget does not provide real standard IO capabilities.
 Under Tk, when redirecting from standard input, all applications will see an
 immediate end-of-file; information redirected to standard output or standard
-error will be discarded.  
+error will be discarded.
 .PP
 Either forward or backward slashes are accepted as path separators for
 arguments to Tcl commands.  When executing an application, the path name
@@ -231,7 +231,7 @@ backslashes only in paths.  Any arguments to an application that specify a
 path name with forward slashes will not automatically be converted to use
 the backslash character.  If an argument contains forward slashes as the
 path separator, it may or may not be recognized as a path name, depending on
-the program.  
+the program.
 .PP
 Additionally, when calling a 16-bit DOS or Windows 3.X application, all path
 names must use the short, cryptic, path format (e.g., using
@@ -269,17 +269,13 @@ present, as is done when launching applications under wish.  It is desirable
 to have console applications hidden and detached.  This is a designed-in
 limitation as \fBexec\fR wants to communicate over pipes.  The Expect
 extension addresses this issue when communicating with a TUI application.
-.RE
-.TP
-\fBWindows NT\fR
-.
+.PP
 When attempting to execute an application, \fBexec\fR first searches for
 the name as it was specified.  Then, in order, \fB.com\fR, \fB.exe\fR, and
 \fB.bat\fR are appended to the end of the specified name and it searches
 for the longer name.  If a directory name was not specified as part of the
 application name, the following directories are automatically searched in
 order when attempting to locate the application:
-.RS
 .IP \(bu 3
 The directory from which the Tcl executable was loaded.
 .IP \(bu 3
@@ -299,67 +295,6 @@ the caller must prepend the desired command with
 because built-in commands are not implemented using executables.
 .RE
 .TP
-\fBWindows 9x\fR
-.
-When attempting to execute an application, \fBexec\fR first searches for
-the name as it was specified.  Then, in order, \fB.com\fR, \fB.exe\fR, and
-\fB.bat\fR are appended to the end of the specified name and it searches
-for the longer name.  If a directory name was not specified as part of the
-application name, the following directories are automatically searched in
-order when attempting to locate the application:
-.RS
-.IP \(bu 3
-The directory from which the Tcl executable was loaded.
-.IP \(bu 3
-The current directory.
-.IP \(bu 3
-The Windows 9x system directory.
-.IP \(bu 3
-The Windows 9x home directory.
-.IP \(bu 3
-The directories listed in the path.
-.RE
-.RS
-.PP
-In order to execute shell built-in commands like \fBdir\fR and \fBcopy\fR,
-the caller must prepend the desired command with
-.QW "\fBcommand.com /c\0\fR"
-because built-in commands are not implemented using executables.
-.PP
-Once a 16-bit DOS application has read standard input from a console and 
-then quit, all subsequently run 16-bit DOS applications will see the 
-standard input as already closed.  32-bit applications do not have this
-problem and will run correctly, even after a 16-bit DOS application thinks 
-that standard input is closed.  There is no known workaround for this bug
-at this time.
-.PP
-Redirection between the \fBNUL:\fR device and a 16-bit application does not
-always work.  When redirecting from \fBNUL:\fR, some applications may hang,
-others will get an infinite stream of
-.QW 0x01
-bytes, and some will actually
-correctly get an immediate end-of-file; the behavior seems to depend upon 
-something compiled into the application itself.  When redirecting greater than
-4K or so to \fBNUL:\fR, some applications will hang.  The above problems do not
-happen with 32-bit applications.  
-.PP
-All DOS 16-bit applications are run synchronously.  All standard input from
-a pipe to a 16-bit DOS application is collected into a temporary file; the
-other end of the pipe must be closed before the 16-bit DOS application
-begins executing.  All standard output or error from a 16-bit DOS
-application to a pipe is collected into temporary files; the application
-must terminate before the temporary files are redirected to the next stage
-of the pipeline.  This is due to a workaround for a Windows 95 bug in the
-implementation of pipes, and is how the standard Windows 95 DOS shell
-handles pipes itself.
-.PP
-Certain applications, such as \fBcommand.com\fR, should not be executed
-interactively.  Applications which directly access the console window,
-rather than reading from their standard input and writing to their standard
-output may fail, hang Tcl, or even hang the system if their own private
-console window is not available to them.
-.RE
-.TP
 \fBUnix\fR (including Mac OS X)
 .
 The \fBexec\fR command is fully functional and works as described.