VP/ix (was Re: VPIX & MKS vi on unix file system

[Michael Richardson]

In article <15422 at bfmny0.UU.NET> tneff at bfmny0.UU.NET (Tom Neff) writes:
>The only reason I bother to suggest sticking with UNIX 'vi' instead of
>the excellent MKS port (that truncate bug aside) is that sitting in VP/ix
>interactively all day long really sucks up cycles.  I prefer to save it

  I can second that statement...

>for compile passes.  Although I must admit the load latency for repeated
>VP/ix one-shots is pretty bad.  (It pays to keep a spare vpix.cnf around
>with NOTHING defined except what you need to get a compile done; and 

  It seems to me leaving a VP/ix around idle is just as bad as using
it --- e.g. it still uses all the CPU it can get. Hitting the sysreq
key and popping into a Unix shell seems to stop that sillyness. /bin/csh
is already loaded, so the hit should only be for the data space and 
.cshrc startup time. (alias vpix '(setenv SHELL=/bin/sh; vpix !$)'
should solve that.)

>lighting the sticky bit on the fastload image seems to help.)  I also

  Can anyone tell me what EXACTLY rundos does? (In the autoexec.bat 
file of VP/ix.)

   It seems to be involved in starting up whatever it was that you had
wanted to run under VP/ix: e.g. vpix start [where start.bat exists in
the current directory] causes start to be "fed" into command.com when 
autoexec.bat gets to rundos. 
   RunDos also seems to want to do dospath, and set the drive to z.
(I finally had to add unixpath to the beginning of start.bat...)
   (btw start.bat sets up a number of drives current directories,
and brings up foxplus because foxpro doesn't like the networked (Unix) drives
and my database file exceed 10meg each and 20 meg total [not that we can find
the old 20meg C: drive anywhere.])

-- 

   :!mcr!:               | Tellement de lettres, si peu de temps.
   Michael Richardson    |  If Meech passes, no one will understand that.
 Play: mcr at julie.UUCP Work: michael at fts1.UUCP Fido: 1:163/109.10 1:163/138