Dos and/or Windows versions of Unix SCRIPT command

Question

Back in university, when we had to submit an assignment in CS, we would have to perform a series of steps including running script, date, whoami, etc., and then running our program.

The script command would pipe all text sent to the display to both the display and a specified file as well.

Ever since, I have been looking for a Dos and/or Windows version, but have come up empty. Some programs can be redirected to a file, but then the display is not echoed, and some programs don’t seem to work with redirection at all.

Any ideas?

---

Edit:

So far, the answers that I’ve gotten seem to work exactly like the standard redirection commands (<, >, |). These do not work with all programs. For example, the Microsoft C++ compiler CL.EXE. If you run cl /? through a redirection command or pipe it through another program (such as TEE), you will not get the header/banner text.

Another example is a program I wrote a while back in Pascal (I think the last compile was in FreePascal). The help text does not get redirected at all. I have seen this occur with other programs as well like MKISOFS. It has a long help text, but cannot be paused by piping it through MORE or redirected to a file!

I have wondered about this for many years. I used to think that it may be because the text is being written directly to the screen (eg port B800) or something, but I have yet to pin down the cause, let alone find a program that can do this job.

Answer 1

Take a look at Cygwin, it gives you access to all those great UNIX command line tools in Windows.

Answer 2

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

Answer 3

I found a Cygwin port of the Unix script command. It captures both STDOUT and STDERR (so it gets the header output from cl.exe).

However capturing cmd.exe commands is a little convoluted for two reasons:

• script spawns a cygwin bash shell (not cmd.exe)
• script does not work when started from a cmd.exe shell; it must be started from cygwin.

You can do it, though:

1. open a cygwin shell.
2. start script
3. start a cmd.exe shell from within the cygwin shell
4. do your stuff in cmd.exe
5. exit out of cmd.exe
6. exit out of script

*also the cmd.exe shell spawned from inside cygwin acts a little strange, but the commands seem to work:

• the window that usually pops up if you try to run cl.exe without first running vcvars32.bat does not come up
• console input is very finicky (for example typing LEFT RIGHT cl or UP cl does not work.)

Answer 4

This General Pascal FAQ explains the cause, as well as a solution for Turbo Pascal programs.

Q. When I redirect the screen output of my programs to a file the file is empty and the output still appears on the screen. What am I doing wrong?

A. You are probably using the CRT unit and its default method of writing to stdout is by direct screen writes. In order to enable output to be redirected all writes must be done by DOS. Setting the variable DirectVideo to false has no effect on redirection as all it does is use the BIOS for screen writes - not DOS.

To enable redirection you must not use the CRT unit

OR

assign(output,'');
rewrite(output);

This will make all output go through DOS and thus can be redirected if desired. To restore the default situation:

AssignCRT(output);
rewrite(output);

Answer 5

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.

Answer 6

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.)

1. 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.

2. 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.