dave@arnold.UUCP (Dave Arnold) (10/04/88)
To all you future filesystem designers, please avoid the following:
SYS$SYSROOT[UTILS.ANUNEWS.SRC.NEWS_SRC]NEWSADD.OBJ;1
NOTE: SYS$SYSROOT is also a logical name which has 2 translations.
Oh yeah, then there is the DECNET node specs:
VAXB"LOGIN PASSWORD":: plus the above.
I prefer:
/sysroot/utils/anunews/src/news_src/news_add.obj
P.S. Did I make a syntax error somewhere?
--
Dave Arnold
dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!davemkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (10/05/88)
In article <206@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) writes: > To all you future filesystem designers, please avoid the following: > SYS$SYSROOT[UTILS.ANUNEWS.SRC.NEWS_SRC]NEWSADD.OBJ;1 > NOTE: SYS$SYSROOT is also a logical name which has 2 translations. > Oh yeah, then there is the DECNET node specs: > VAXB"LOGIN PASSWORD":: plus the above. > I prefer: > /sysroot/utils/anunews/src/news_src/news_add.obj It's even more fun when you decnet copy between Ultrix and VMS because VMS thinks "/" means a command line option switch (so you have to quote Unix pathnames), and csh thinks all sorts of horrible things about "$", ":", "[", "]", and ";" (so you have to '-quote the whole mess). On top of that DEC had to invent totally different ways of specifying username and password for Ultrix, and Ultrix's dcp (decnet cp) is strictly 1 file per invocation (blecch). At least Ultrix decnet lets you omit your password on the command line, and let you supply it UNECHOED in response to a prompt. I don't know if it's fixed in VMS 5.0, but VMS 4.x decnet was pretty brain-damaged to require that you type your password in a nodespec for the whole world to see. One good feature of Ultrix decnet is tcp/decnet gatewaying. It lets a Unix host telnet and ftp to a VMS host that doesn't run tcp/ip services. It even works for non-VAX Unix machines (e.g., Suns). Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
thierbac@umbc3.UMD.EDU (Ed Thierbach ) (10/06/88)
In article <25312@teknowledge-vaxc.ARPA> mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: >[...] >At least Ultrix decnet lets you omit your password on the command line, >and let you supply it UNECHOED in response to a prompt. I don't know >if it's fixed in VMS 5.0, but VMS 4.x decnet was pretty brain-damaged to >require that you type your password in a nodespec for the whole world to see. Actually, although V3.x and earlier did indeed have this problem, V4.0 introduced something called "proxy logins". The system manager of each site can set up a correlation (sp?) between userids on different systems, so that the username and password can be left off. For example, I can specify a proxy such that VAXA::ED (the remote node) corresponds to VAXB::BIG_CHEESE (local node) -- so if I'm on VAXA I can type: $ COPY VAXB::LOGIN.COM to copy the LOGIN.COM file from BIG_CHEESE's login directory on VAXB. It's pretty nifty, and the old NODE"USER PASSWORD"::etc. still works if you need it. What *doesn't* work is NODE"USER PASSWORD1 PASSWORD2":: for those of us who use two passwords on sensitive accounts. (Could someone bring this up at DECUS? I won't be there this time ... sigh) V5.0 brings you the ability to set up multiple proxies for a single remote user, so he/she can specify the account desired. Take a look at the VAX/VMS Networking manual; it gives a pretty good description. --- Ed Thierbach VAX System Manager Roy F. Weston, Inc. thierbac@umbc3.umd.edu (guest account...mail seems better behaved these days)
cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (10/08/88)
In article <25312@teknowledge-vaxc.ARPA>, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: > In article <206@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) writes: > > To all you future filesystem designers, please avoid the following: > > SYS$SYSROOT[UTILS.ANUNEWS.SRC.NEWS_SRC]NEWSADD.OBJ;1 > > NOTE: SYS$SYSROOT is also a logical name which has 2 translations. > > Oh yeah, then there is the DECNET node specs: > > VAXB"LOGIN PASSWORD":: plus the above. > > I prefer: > > /sysroot/utils/anunews/src/news_src/news_add.obj > Speaking as a 3-year VMS veteran who's been munging about in UNIX for about a year now, I find that I prefer VMS file- and directory-specs, because I can tell at a glance whether the entity I am ultimately referencing is a file or a directory. In UNIX I have to wait to enter my command and then receive an error message to the effect that the entity I referred to was the wrong kind. On the other hand, it IS quicker to type slashes and names, than colons and brackets and dots and names... All in all, I can use EITHER system quite conveniently and I find that to be true on ALL computers, bar none, that I have tried: Atari and Commodore 8bits, Amigas, Intel minis, PC's with MS-DOS, and a slew of others. All it takes is some getting used to. Sometimes I think people just want instant comprehension and get all honked off when faced with a "learning curve." Perhaps I'm wrong, but isn't it really just a matter of calming down and paying attention to what you're doing, rather than quibbling about notation? Chris -- UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP
gwyn@smoke.ARPA (Doug Gwyn ) (10/09/88)
In article <4243@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher Chiesa) writes: >but isn't it really just a matter of calming down and paying attention to >what you're doing, rather than quibbling about notation? No, a well-chosen notation can make possible things that one wouldn't dream of doing under other circumstances. A uniform hierarchical naming scheme offers opportunities for simple grafting on of subsystems, generalized mounts, etc. that an erratic naming scheme does not.
sommar@enea.se (Erland Sommarskog) (10/10/88)
Dave Arnold (dave@arnold.UUCP) writes: >To all you future filesystem designers, please avoid the following: >SYS$SYSROOT[UTILS.ANUNEWS.SRC.NEWS_SRC]NEWSADD.OBJ;1 >I prefer: >/sysroot/utils/anunews/src/news_src/news_add.obj On the other hand, on VMS you can do the following: DEFINE/TRANSLATION=CONCEALED NEWS_ROOT SYS$SYSROOT:<UTILS.ANUNEWS> (This may be the wrong syntax. My apoligies if so.) and then refer to the file as NEWS_ROOT:<SRC.NEWS_SRC>NEWSADD.OBJ. Or why not proceed with: DEFINE NEWS_SRC NEWS_ROOT:<SRC.NEWS_SRC>, and then simply say NEWS_SRC:NEWSADD.OBJ. On Unix you can of course do: setenv NEWS_ROOT /sysroot/utils/anunews and refer to the file as $NEWS_ROOT/src/news_src/news_add.obj but it doesn't seem like that translation of enviroment variables is built in the file system as logical-name translation is on VMS. Thus, you can't be sure that every utility you use will understand $NEWS_ROOT, in which case you have to remember the entire path. (I may be totally wrong about Unix here. If so, please correct me.) -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP
hedrick@athos.rutgers.edu (Charles Hedrick) (10/10/88)
>Speaking as a 3-year VMS veteran who's been munging about in UNIX for about a >year now, I find that I prefer VMS file- and directory-specs, because I can >tell at a glance whether the entity I am ultimately referencing is a file or >a directory. In UNIX I have to wait to enter my command and then receive an >error message to the effect that the entity I referred to was the >wrong kind. I'm not sure exactly what kind of problem you are having, but do you know about the -F argument to ls? I do "alias ls ls -F" so that I always get it. -F causes file names displayed by ls to have / tacked onto the end if they are directories and * if they are executable. At least on our Pyramid this exists in both Berkeley and Sys V versions of ls. This is intended to make it clear what kind of object a file is. Also, you may find it convenient to use one of the shells that lets you check for things that match what you've typed so far when you are in the middle of typing a file name. ksh and the 4.3 csh do this.
eirik@tekcrl.TEK.COM (Eirik Fuller) (10/12/88)
In article <3981@enea.se> sommar@enea.se (Erland Sommarskog) writes:
) ...
) >I prefer:
) >/sysroot/utils/anunews/src/news_src/news_add.obj
) ...
) On the other hand, on VMS you can do the following:
) DEFINE/TRANSLATION=CONCEALED NEWS_ROOT SYS$SYSROOT:<UTILS.ANUNEWS>
ln -s /sysroot/utils/anunews /news_root
gives the name /news_root/src/news_src/news_add.obj
Doesn't help much if your flavor of Unix has no symlinks though.
Does VMS store this alias in the file system? Does it survive
reboots? Never mind, I don't really want to know :-)eric@snark.UUCP (Eric S. Raymond) (10/12/88)
In article <3981@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > On the other hand, on VMS you can do the following: > DEFINE/TRANSLATION=CONCEALED NEWS_ROOT SYS$SYSROOT:<UTILS.ANUNEWS> > (This may be the wrong syntax. My apoligies if so.) <chortle> Does anyone else see the funny here? The VMS syntax is so flinkin' obscure that you can't be sure you've got it right. Compare the alphabet-soup VMS command above with the more-or-less equivalent UNIX link invocation: ln /usr/bin/utils/anunews /newsroot Now: which would *you* rather wake up next to? :-) In a less facetious vein: which of the above requires less mental parsing, fewer interpretation rules with fewer exception cases? *This* is what Dave Arnold was getting at. Arguing that VMS's baroque syntax supports a feature UNIX doesn't isn't an appropriate counter, especially when you're wrong ;-). > Thus, you can't be sure that every utility you use will understand > $NEWS_ROOT, in which case you have to remember the entire path. > (I may be totally wrong about Unix here. If so, please correct me.) This is exactly what UNIX links are for, especially BSD-style symbolic links (which AT&T is supposedly including in 4.0). -- Eric S. Raymond (the mad mastermind of TMN-Netnews) UUCP: ...!{uunet,att,rutgers}!snark!eric = eric@snark.UUCP Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/14/88)
In article <3981@enea.se> sommar@enea.se (Erland Sommarskog) writes: >On the other hand, on VMS you can do the following: >DEFINE/TRANSLATION=CONCEALED NEWS_ROOT SYS$SYSROOT:<UTILS.ANUNEWS> Well, assuming you have done so, how do you then specify a subdirectory inside NEWS_ROOT? -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
sommar@enea.se (Erland Sommarskog) (10/16/88)
Eric S. Raymond (eric@snark.UUCP) writes: >In article <3981@enea.se>, sommar@enea.se (Erland Sommarskog) writes: >> On the other hand, on VMS you can do the following: >> DEFINE/TRANSLATION=CONCEALED NEWS_ROOT SYS$SYSROOT:<UTILS.ANUNEWS> >> (This may be the wrong syntax. My apoligies if so.) > ><chortle> Does anyone else see the funny here? The VMS syntax is so flinkin' >obscure that you can't be sure you've got it right. As for the fun save the smiles. Unix often gives raise to questions as what was that one-letter option again? And should the argument to the option be separated with a space or not? The problem to remember the exact form for a construct seldom used appears with any OS. >Compare the alphabet-soup >VMS command above with the more-or-less equivalent UNIX link invocation: >ln /usr/bin/utils/anunews /newsroot Nothing wrong with links, and as long we only want /newsroot to point to the same place all the time, it does the same job as the logical name above. But logcial names do more than so. Let's say that NEWS_ROOT above in defined in the system table. (Which means that the name live until the system dies. Preferably its definition is in the start-up file.) Now I get a new version of NEWS which I like to experiment with before I install it for everyone. In the logical-name table for my process I define NEWS_ROOT to point were the new version lies. This definition overrides the system table, but for my process only. I could even say that NEWS_ROOT is a search list that points to many places. If a file isn't found in the first directory it points to, the file system will look in the next one and so forth. Some of this, if not all, is surely available in Unix. But I fail to intuitively see how symbolic links is the thing in these cases. Enviroment variables come close, but, again, are they always supported? >In a less facetious vein: which of the above requires less mental parsing, >fewer interpretation rules with fewer exception cases? *This* is what Dave >Arnold was getting at. Arguing that VMS's baroque syntax supports a feature >UNIX doesn't isn't an appropriate counter, especially when you're wrong ;-). Which naming scheme is the best is a discussion I rather stay out of. I wrote my article to point to that VMS actually doesn't require you to write all that Dave Arnold claimed. It comes a no surprise that Unix have an equivalent feature. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP
eal@tut.fi (Lehtim{ki Erkki) (10/16/88)
In article <206@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: > > >SYS$SYSROOT[UTILS.ANUNEWS.SRC.NEWS_SRC]NEWSADD.OBJ;1 >P.S. Did I make a syntax error somewhere? Yeah, you did. SYS$SYSROOT:[UTILS.ANUNEWS.SRC.NEWS_SRC]NEWSADD.OBJ;1 is correct one. -- Erkki A. Lehtim{ki eal@tut.uucp "I don't eat nutrasweet"