rad@mitre-bedford.arpa (Dick Dramstad) (01/23/87)
Robert,
>I was not aware anywone had written a VMS shell (or would want to) for UNIX.
Someone has. At the Fall DEXPO in San Francisco, Convex (the
makers of a Unix mini-supercomputer) showed their VMS environment
running on their C-1 machine. (It looked like all it consisted of was
a bunch of aliases and shell scripts.) It complements their VAX/VMS
FORTRAN (source-code) compatible extended compiler. I'm sure their
reason for doing this was to attract the FORTRAN-coding engineers who
have grown used to VMS and its compiler but could really use the extra
speed the C-1 could give them.
Comment: It may not be ideologically pure, but the
combination of an inexpensive fast machine, a familiar-feeling FORTRAN
development environment, as well as access to all those nice Unix
software development aids *must* be commercially attractive in some
quarters.
Dick Dramstad
rad@mitre-bedford.arpadalem@hpfcph.UUCP (01/24/87)
[discussion of emulators on various systems, etc.]
I guess I didn't make my point clearly enough. I said that one could
write a shell similar to DCL to run on UNIX quite easily, but writing a
shell similar to sh or csh to run on VMS would be tough. Note that I did
NOT say it would be impossible. One of the major differences between the
two systems is that with one system you only have to edit /etc/passwd and
put the name of the shell in; under the other one you must modify
sys$system:sysuaf.dat, install the shell in some special place, etc. Note
that this process is not documented (or if it is, it is *well* hidden).
Another thing to keep in mind has already been mentioned - VMS is slow in
doing an equivalent of a fork()/exec() - something that is pretty fundamental
to a shell. If one looks at the microfiche source for DCL, they are using
an undocumented call to run programs. If you call DEC and ask about it, they
will deny its existence. This leaves Joe Hacker with the choice of LIB$SPAWN
or SYS$CREPRC for doing his fork()/exec(). Both are horribly slow.
Note that this information is a few months old - it dates back to Spring 1986,
VAX/VMS V4.2.
Someone noted that one reason there are no VMS emulators on UNIX is that noone
would want one. A *very* good point. VMS has some nice features (a good
backup/restore facility, the ability to rename a directory as a Joe User, the
ability to refer to the current directory and everything below it, etc.), but
has some pretty fundamental problems.
Dale McCluskey
{hplabs,ihnp4}!hpfcla!dalemgillen@convexs.UUCP (01/28/87)
Maybe I should just say nothing but.... The VMS-like shell that you refer to is marketed as the "COVUEshell." I think that the word COVUE stands for something like the "CONVEX-VAX User Environment." Anyway, it's a lot more than "shell scripts and aliases." It's truly a shell that provides a subset of the commands and features provided by DCL. What's it got? Well, it feels pretty much like DCL. You can create and use simple command procedures. Many of the lexical functions were implemented. There's an interface to the CONVEX UNIX Batch System so that the SUBMIT and SHOW QUEUE commands work like VMS. There are global symbols and process-wide logical names. There's even a MLisp file to make Emacs look close to EDT. What's missing? Large, sophisticated command procedures will break. No local symbols, system-wide, or group-wide logical names. Many of the esoteric command switches are missing. The concept of physical devices is pretty weak (nearly nonexistant) but that's to be expected since it's attempting to map VMS filename syntax to UNIX filename syntax. Not all of the DCL commands have been implemented. Those that do exist enforce an ordering of switches and arguments like any UNIX shell. How does it work? As I said above, COVUEshell isn't aliases and shell scripts. It's a shell that parses your DCL command and converts it to the corresponding UNIX (Bourne shell) syntax. A child is forked that performs this command. Pretty slick, actually. For the system manager- type that wants to wean users from VMS into the UNIX domain, there's a Learn Mode that can be enabled that will display the equivalent UNIX command that is going to be executed. COVUEshell doesn't eat your machine alive, either. It's surprisingly supple. I'm not trying to sell COVUEshell (or drum up business for CONVEX). No, I'm not one of the developers of it, either. I just use it daily in the course of my development work at CONVEX. I'm an old VMS hand who got tired of the cryptic UNIX commands. Overall, if the goal is to give users familiar with VMS a "warm and fuzzy feeling," COVUEshell does the trick. Dave Gillen Credits and Disclaimers The above opinion is mine and does not reflect the opinion of CONVEX. DCL, EDT, VAX and VMS, are trademarks of Digital Equipment Corporation. COVUE is a trademark of CONVEX Computer Corporation. UNIX is a trademark of the AT&T Bell Laboratories. "Gillen" isn't a trademark but I'm grateful to Mom and Dad for it. I can't sing and I can't dance, guess I'll have to program for a living.
mouse@mcgill-vision.UUCP (02/05/87)
In article <3700003@hpfcph.HP.COM>, dalem@hpfcph.HP.COM ( Dale McCluskey) writes: > [discussion of emulators on various systems, etc.] > If one looks at the microfiche source for DCL, they are using an > undocumented call to run programs. If you call DEC and ask about it, > they will deny its existence. I didn't know *that*. Yech. > This leaves Joe Hacker with the choice of LIB$SPAWN or SYS$CREPRC for > doing his fork()/exec(). Both are horribly slow. $IMGACT (or was it $IMGSTA?) does not do a fork/exec, it just does the exec. The image being run runs in the *same process* as the CLI ("shell"). This is a major difference of philosophy; under VMS your process has a CLI in P1 space which runs programs in P0 space, one at a time. Under UNIX the shell is running just as if it were a normal user program is (which it in fact is, or at least was before the recent getusershell() nonsense came along [mutter, grumble]). > VMS has some nice features (a good backup/restore facility, Needed. > the ability to rename a directory as a Joe User, UNIX has this, at least modern UNIX. rename() works on directories (without needing privilege). I don't know whether USG UNIX has anything like rename(), but if they don't, well, that's just another thing wrong with USG UNIX, no? > the ability to refer to the current directory and everything below > it, Or any directory and everything below it, for that matter. However, this would be easy to put into the shell's globbing routines. Most applications of it can be better addressed with find and xargs, which may explain why it isn't there already. > etc. You missed just about the only VMS thing I miss: the debugger. VMS had a *good* debugger, certainly better than anything I've seen on UNIX. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu
dalem@hpfcph.UUCP (02/11/87)
> > $IMGACT (or was it $IMGSTA?) does not do a fork/exec [...] And where does one find the documentation on $IMGACT? > > > the ability to rename a directory as a Joe User, > > UNIX has this, at least modern UNIX. rename() works on directories s/modern/BSD/ :-) Dale McCluskey {hplabs,ihnp4}!hpfcla!dalem