23

I am currently experimenting with DOS and am trying to run the command prompt on the serial terminal through QEMU. This is the command I have been using.

command >COM1 2>COM1 <COM1

This should in theory connect command.com's stdin, stdout, and stderr to the terminal at COM1. However, it only seems to redirect stdin and stdout. How can I redirect stderr properly so that error messages appear on COM1?

0

3 Answers 3

48

That's because MS/PC-DOS can not redirect STDERR.

This feature was only added later with the shells of OS/2 and Windows NT

Having said that, what you want to do isn't redirecting the streams, but putting the console on another device. That's what CTTY is all about. In this case

  ctty com1

will do the trick. CTTY is available starting with DOS 2.0. It takes any device name, even CLOCK and LPT - which of course may not make much sense :))

8
  • 10
    ... and NUL if you want to shoot yourself in the foot! Dec 22, 2021 at 17:25
  • 2
    ahh thanks, works great! so it's basically getty but for dos! Dec 22, 2021 at 19:11
  • 17
    I thought I knew MS-DOS pretty well but I don't remember CTTY at all! Cool ...
    – davidbak
    Dec 23, 2021 at 0:35
  • 3
    @davidbak I do remember it because it was "that command that would make your computer useless until you rebooted".
    – hobbs
    Dec 24, 2021 at 1:57
  • 1
    @davidbak I remember it as the command you would have to manually type in to install Interlnk and Intersvr, which would allow you to connect computers via a null modem cable. It was essential in setting up the computer lab where a lot of the floppy drives didn't work.
    – trlkly
    Dec 25, 2021 at 2:32
24

As Raffzahn says, you can’t redirect standard error under DOS, at least not with the standard COMMAND.COM. With 4DOS, both output streams can be redirected with >&. That would allow you to redirect to a file as well as a device.

Instead of trying to redirect the input and output streams to use a serial connection, under DOS you’d change the TTY:

ctty com1

This will work with any character device (with varying results if the character device isn’t appropriate).

Note that many DOS programs don’t use the standard input and output streams, but read from the keyboard and write to the screen without using DOS services; such programs won’t honour redirection or CTTY and won’t work over a serial connection.

(Amusingly enough, DOS has five standard device handles: standard input, standard output, standard error, standard auxiliary and standard list. The first three are attached to CON by default; the fourth to AUX, and the fifth to PRN.)

3
  • 1
    Interesting bit about 4DOS, as the NT syntax uses this as additional parameters with the stream numbers command >com 1>&2.
    – Raffzahn
    Dec 22, 2021 at 17:20
  • 4
    @Raffzahn: The 1>&2 syntax was adopted from UNIX, which had it at least as far back as V7 (it's in the manual). (Or maybe from some common ancestor.) The shorthand >& is also from Unix but I guess later. Dec 22, 2021 at 18:42
  • 1
    @NateEldredge Sure. After all, MS-DOS .0 was designed with a clear goal to bridge from CP/M (which 1.x essentially was) over to Xenix, which MS considered the future. Except they never added that part. It doesn't make that much sense in a single user single tasking system. So it was up to NT&OS/2 to introduce the use case to catch stderr when running in background.
    – Raffzahn
    Dec 23, 2021 at 13:52
5

As it happens, when launching a new copy of COMMAND.COM, you can simply pass the name of the terminal device as a command-line parameter, as in:

command com1

This is only available specifically when launching COMMAND.COM (whether from another command prompt or from the SHELL= directive in CONFIG.SYS); it is not a generic redirection syntax for an arbitrary command.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .