Dos and/or Windows versions of Unix SCRIPT command

"Okay, so as usual, I took it upon myself to write the program. I had a bit of free time tonight and threw together a native (ie, non-Cygwin) test program that works exactly as I had hoped, albeit with two limitations. (I don’t have an always-on host, but I’ll see to cleaning up the program, writing docs, and releasing it.)

It cannot capture output from programs that write directly to the video hardware (or virtualized hardware as the case may be), so the Pascal program I mentioned cannot be captured unless I recompile it without the direct flag set—which incidentally became unnecessary when I recompiled it with FreePascal.

It cannot receive input from stderr. For example, if you execute cl /? | script.exe c:\test.log, only the help text of the Microsoft compiler will be sent to the file; the banner will only be displayed on the screen. (This is somewhat baffling due to the way the program works, so I’m going to look into it.)

There’s little that can be done about problem (1) (I would not be surprised if there were some clever person somewhere who could figure out a way to intercept direct screen writes, but for all intents and purposes, it’s probably unlikely.)
Problem (2) can be worked around by redirecting stderr to stdout before piping it as follows. It’s not pretty (or as convenient, but it works).
cl /? 2>&1| script.exe c:\test.log

It may/should also be workable from program’s side, thus simplifying the pipe, but I have yet to find any information on how (at least in a “normal/official” way, eg via C++). I do have an idea about installing an interrupt handler in the interrupt vector table to intercept calls to the common ouput API functions, which may/probably will work. In fact, in 1998, I had written an experimental DOS TSR (that also works in the Windows NTVDM), which intercepts output functions and colors them (ie, generic syntax-coloring) before sending them to the screen. It would/should be easy to adapt it to also send a copy to a file."

"Unfortunately, it seems that you won't have luck finding an out-of-the-box Microsoft solution. You can check out a similar post on StackOverflow. The digest:

look at the Win32 port of tee on SourceForge
use Cygwin, as Frank Szczerba also mentions
look at Rob van der Woude's tee implementation in a DOS Batch script
a couple more opinions"

"Many alternatives to CMD make life easier on many fronts, including solve the problem you have indicated of the missing script command. I used PowerCMD and it redirects the output to it's log folder by default. So as an end user you will see the commands as you type and the errors and output of the commands while simultaneously all your work is being ""logged"" in a log file.

To configure it in PowerCMD go to File --> Preference --> Auto Save.

Snippet from the log file that is being automatically populated as I work on PowerCMD,

c:\Software\Microsoft\SysinternalsSuite>date
The current date is: Fri 02/13/2015
Enter the new date: (mm-dd-yy)
c:\Software\Microsoft\SysinternalsSuite>someBadCommand
'someBadCommand' is not recognized as an internal or external command,
operable program or batch file."

"This is really two questions in one, one for DOS and one for Windows, albeit that the answer is the same for both.

It it simply not possible for such a program to exist.

There are two basic variants of script on Unices and on Linux. One (such as this Linux version) uses pipes, the other (such as this HP/UX version) uses pseudo-terminals to avoid the problems with TUI programs that present ""full screen"" interfaces that the pipe approach has. Windows NT simply does not have a pseudo-terminal mechanism. It is simply not possible to capture the I/O to and from a console on Windows NT as it is with pseudo-terminals on POSIX systems. One could use the pipe approach, but …

… DOS doesn't have a pipe mechanism. (Don't be confused by what you can do in DOS command interpreters. Those are not pipes.)
… on Windows NT it will suffer from the problems — much the same as for the pipe approach on Unices and Linux — that …

… some programs will recognize that their standard output is not a console and act differently.
… other programs that treat the pipe like a console will fail, because pipe devices don't support the console-specific system calls.

Cygwin relies upon the coöperation of the target programs in a collective pretense.

You might be wondering about the Cygwin script command, and why it has the not-quite-right behaviour with non-Cygwin programs that it has.

Cygwin tries to emulate pseudo-terminals, using Windows NT pipes. It relies upon the fact that every Cygwin program uses a Cygwin runtime library that ""knows"" when a pipe is ""really"" a pseudo-terminal, using information private to the Cygwin runtime library, and acts accordingly. The runtime library's isatty() function says ""yes"" when the runtime sees a pipe that is ""really"" a Cygwin pseudo-terminal. So Cygwin programs run by Cygwin's script will act as if they are connected to (pseudo-)terminals.

Of course, non-Cygwin programs, that don't participate in this collective delusion, will just see the pipes as they truly are, as pipes, and behave as they do when their standard inputs/outputs/errors are pipes."