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
tli@usc-oberon.UUCP (Tony Li) (08/10/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?)
SET FILE/ENTRY in VMS is a serious kludge and is not meant to be used in cases
where one entry might be deleted. There is no link count, and there are no
inodes to speak of. There is an index to the system and the link count
could be kept there.... but it's not. Basically, SET FILE/ENTRY is a very
dangerous feature which is not properly supported.
--
Tony Li ;-) Usc Computer Science
Uucp: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!tli
Bitnet: tli@uscvaxq, tli@jaxom, tli@ramoth
Csnet: tli@usc-cse.csnet
Arpa: tli@usc-ecl.arpajbuck@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