mwm@eris.berkeley.edu (08/07/86)
In article <859@kbsvax.steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes: >What really made this answer so obnoxious is that after all this >overkill flame, the poster didn't say (or, could it be, didn't know) >that the user can define his/her commands with a mechanism similar to >an alias, and get no parameter checking at all. It can even be put in a >startup file and done at login. > >Examples: (! starts comments) > $ check:==$usr$disk:[user.bin]check.exe ! binary executable image > $ redo:==@usr$disk:[user.bin]redo.com ! DCL (shell) command file [Explanation of syntax deleted. It's like a Bourne shell variable assignment, with `:==' replacing `='.] You forgot what I considered the nicest feature of the VMS alias mechanism: $ r*edo:==<etc> will make any prefix of "redo" down to "r" valid as a redo. Similarly, $ ch*eck:==<etc> will make any prefix of "check" down to "ch" a valid as a check. Nice feature, that. I just wish some Unix shell (ksh, preferably) had it. >Please don't count me as pro-VMS, I have used it since we got our first >VAX (I believe it was S/N < 30) and still only consider it acceptable. >I find the UNIX interface more convenient and the response far better >for small programs due to the overhead of process start in VMS. I've used Unix since v6, and VMS since 1.5 or so, and they are both only acceptable - and each only for some subset of all possible applications. I do find the Unix interface more convenient, but I found the response for small programs better on loaded systems under VMS. Not sure why (but I have my suspicions), and of course the load & configuration (and which version of what is running) are never the same on those systems. <mike
levy@ttrdc.UUCP (Daniel R. Levy) (08/08/86)
In article <1065@jade.BERKELEY.EDU>, mwm@eris.berkeley.edu writes: >You forgot what I considered the nicest feature of the VMS alias mechanism: > > $ r*edo:==<etc> > >will make any prefix of "redo" down to "r" valid as a redo. Similarly, > > $ ch*eck:==<etc> > >will make any prefix of "check" down to "ch" a valid as a check. Nice >feature, that. I just wish some Unix shell (ksh, preferably) had it. > That might be a good idea, but you can also get this effect by using ln to link the executable to entries by the shorter names, e.g. ln /bin/who /bin/wh ln /bin/crypt /bin/cryp; ln /bin/crypt /bin/cry; ln /bin/crypt /bin/cr; (Which prompts another aside on VMS; why oh why is there a SET FILE/ENTRY under VMS if DELETE-ing the extra entry blows away the file data itself, leaving any other entries for that file invalid? Why isn't a link count kept a la the UNIX (TM of AT&T) OS even if VMS doesn't have inodes?) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
jbuck@epimass.UUCP (Joe Buck) (08/11/86)
In article <1122@ttrdc.UUCP> levy@ttrdc.UUCP writes: >(Which prompts another aside on VMS; why oh why is there a SET FILE/ENTRY >under VMS if DELETE-ing the extra entry blows away the file data itself, >leaving any other entries for that file invalid? Why isn't a link count >kept a la the UNIX (TM of AT&T) OS even if VMS doesn't have inodes?) VMS does have the equivalent of inodes; they're blocks in the index file, pointed to by the FID. The index file looks very much like the inode list of Unix. It would take very little work to add a link count to the index block and change $DELETE to Unix behavior. There are a couple of barriers to making the behavior identical -- for one thing, the filename (but not the directory name) is stored in the index block, but this is mostly relevant when a lost file is recovered (because, say, a user blew away a directory entry with SET FILE/REMOVE). But VMS could handle links properly without that much effort, and users wouldn't notice the change. -- - Joe Buck {ihnp4!pesnta,oliveb,nsc!csi}!epimass!jbuck Entropic Processing, Inc., Cupertino, California