3

I am using CVS 1.3 in MS-DOS 6.22.

When I execute cvs -?, the top of the help output scrolls off my 80x25 screen.

I cannot redirect the output to file as I suspect it is streamed to stderr (eg. cvs -? > output.txt generates a 0 byte file).

I have also tried piping to less (for DOS) but it also does not capture the output.

How do I capture stderr in DOS ?

Link to programs:

user3840170
  • 23,072
  • 4
  • 91
  • 150
mvanle
  • 131
  • 3

3 Answers3

1

MS-DOS COMMAND.COM doesn’t support redirecting standard error, but 4DOS can take care of it:

  • command >& filename redirects both standard output and standard error to filename (which can be a file or a device)
  • command >&> filename redirects standard error only to filename

Using >> instead of the first > in each variant above will append rather instead of overwriting the target file.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
1

The default MS-DOS shell, COMMAND.COM, does not provide any way to redirect standard error. Doing this requires a different shell, or an external utility. (This problem is sufficiently well known that some command-line programs provide dedicated options to write error messages into a file. NASM, for example offers a -Z option, previously spelt -E, for that purpose.)

One such external utility is REDIR, found within the DJGPP distribution, which supports redirecting standard output and standard error both in overwrite and in append mode, joining the streams together, and a couple of other, mostly unrelated features. Like other DJGPP programs, it requires a DPMI DOS extender to run, so it can be considered relatively heavyweight.

If you are looking for something lighter, a program named ERROUT will suffice to join standard error into standard output, which is just enough to send verbose help output into a pager.

user3840170
  • 23,072
  • 4
  • 91
  • 150
0

stderr can't be redirected in DOS.

However, if your objective is to get command line help for CVS (there's a tool I haven't come across for many years), it's almost certainly identical on DOS and Unix and there are online resources that tell you what the command line options are.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
JeremyP
  • 11,631
  • 1
  • 37
  • 53
  • 9
    It can be redirected in DOS, just not with COMMAND.COM. – Stephen Kitt May 23 '23 at 11:56
  • @StephenKitt While it can be redirected, the shell may expect any process's stderr to refer to a device rather than a file. I know that FreeCOM's interrupt 24h handler (Critical Error handler) expects stderr to be open, and will apparently hang if you invoke the critical error handling while stderr is closed. I wrote about such a case some on my tech blog: https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0501_late_april_work_on_the_debugger#device_attribute_change – ecm May 23 '23 at 18:51
  • 1
    @ecm does it hang because stderr is closed, or stdin? (I can’t easily check the code right now...) Admittedly if stderr is closed, the message won’t go anywhere, so the user won’t know to choose anyway. – Stephen Kitt May 23 '23 at 19:24
  • 1
    @StephenKitt As I expected, and I believe MS-DOS does too, FreeCOM uses the current process's stderr to (temporarily) replace both its stdin and stdout, then operates on those using normal DOS functions. Here's the bit of the handler that does this replacement: https://github.com/FDOS/freecom/blob/1a8359c1683217c9bf9ebcca7e25258529c05e7e/criter/criter.asm#L400 I knew that it does this because it is expected that stdin and stdout may be redirected using the shell's normal redirection capabilities. So the critical error handler must not use the original handles for those. – ecm May 23 '23 at 19:38