new DOSMerge

[Leslie Mikesell]

In article <14439 at bfmny0.UUCP> tneff at bfmny0.UUCP (Tom Neff) writes:

>>You can run any DOS program from a UNIX makefile, but you cannot run the
>>make in the background or redirect output of the make (VP/IX needs a console).

>I redirect VP/ix output all the time. 

Just to be perverse, I logged in to a 386 running AT&T unix over a starlan
network, started an interactive shell in GNU emacs and ran some DOS commands.
They mostly worked, except for the CR's at the ends of lines, which can be
fixed by loading the kermit library and setting kermit-clean-on.  I couldn't
quite get an interactive command.com to work.  Even with kermit-default-cr
it seemed to lose most of the input characters.  It did look like it
would be possible to run something like dos ndmake with the compile
command and parse the results with next-error.

>You only need DOSPATH if you want to be able to fire off EXE/COM/BAT
>files from the shell prompt as if they were UNIX commands.  If you are
>willing to type 'dos command' rather than 'command', you can run
>anything DOS can get at, even stuff in pseudodisks like "C:" or in real
>DOS partitions on your hard disk (if you have VP/ix set up to access
>it), whether or not it lies in DOSPATH.

I see a real problem with the reverse effect (i.e. under DOS executing
a unix command by typing its name).  If you happen to have your DOS
current drive set to something that unix doesn't understand (like
the floppy or a dos partition of the HD) the unix command will execute
in the directory where you started the dos process.  For example, you
might start dos from your home directory, change to the A: drive and
accidentally type rm * to delete everything instead of del *.*.  Guess
what gets erased...

Les Mikesell