Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: Symbolic Links Message-ID: <8731@brl-adm.ARPA> Date: Mon, 10-Aug-87 15:03:42 EDT Article-I.D.: brl-adm.8731 Posted: Mon Aug 10 15:03:42 1987 Date-Received: Tue, 11-Aug-87 05:01:03 EDT Sender: news@brl-adm.ARPA Lines: 131 From: Doug Gwyn In article <7956@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >Dave Korn writes: > About 50% of the respondents agreed with me completely. Another 30% >The best way to do something wrong is to take a poll (especially if >it includes naive users) and implement the result. The point of the poll was to garner sufficient "public" support to get the internal AT&T decision makers to seriously consider Korn's proposal. I'm sure Korn was not relying on the poll to help him determine the TECHNICAL viability of his proposal, but rather the POLITICAL viability. You didn't address the issue. I know what his point was. BTW, do you really think TPC will listen to the net's desires? It'd be a first. > 2. The directory of .. must be independent of the way you got there. > Note that this has already been broken by > a. Remote mounts in RFS >Please explain. I hope that you are not using RFS's (possible) botches >to justify botching something else. BTW, NFS seems to work correctly. Cottrell, if you don't know what you're talking about then shut up. RFS is doing exactly the right thing in this case. My lack of specific knowledge of an obscure remote file system does not invalidate my general argument. I was asking him to justify his statement. BTW, NFS is hardly a model for "correct" semantics for UNIX file systems! Great, you just insulted Sun. >Good point. However, before you guys tackle something complex like >symbolic links, perhaps you had better finish the job on regular file >systems and implement `mkdir', `rmdir', and `rename' as system calls Mkdir & rmdir ARE system calls in the current version of UNIX. Well congratulations! It only took them how long? We only have SVr2v2 here, and only get it as an excuse to run Berkeley. Still, I do look at the docs from time to time, and load a few useful programs from it. It is not especially advantageous to do this for ordinary file systems, but it certainly is for a distributed file system. Rename is more difficult and less urgent, but it too will probably move into the kernel soon. They are useful because they make directorys more like files. No bogus mvdir or mvtree (or whatever) commands. And no races on rename. Your patronizing tone is totally inappropriate. Well, excuse me. I didn't get any response with a polite, detailed reply. BTW, aren't we the pot calling the kettle black? I interrupt this stream of consciousness to quote another article of yours: Consider: During the early stages of porting my software to a new hostile (i.e. 4BSD) system, I use a shell script named "cc" to get Hostile? `cc' is probably one of the more standardized commands. things compiled right. No way am I going to edit a zillion Makefiles to redefine "cc" to "cc.sh", then later change them back. I agree. (Admittedly augmented "make" provides a way to accomplish this through use of an environment variable, Admittedly, so does vanilla make: `make CC=cc.sh target' but the point is that the name of a command should encode only the command's function, not information about its type, creator, size, or other irrelevancies.) Such as the method of execution. You see? I can be agreeable too. Okay, now back to the previous article: I know several AT&T software developers (including Korn) who can run rings around you. Good taste is just as important as sheer prowess. Perhaps more. Their biggest problem lies in the bureaucracy that lies between their prototypes and the official released product. To some degree this does make for higher quality (virtually every recent new feature in UNIX System V has had an improved design over the original prototype), but it does delay or even discourage the appearance of new features. No argument there. I will restate my position for anyone who missed it. 1) The idea of following `cd /a/b' with `cd ..' and ending up in `/a' is an attractive one, no doubt. There are many ways of doing this. One is to do it in the shell, possibly with a switch enabling it. In fact, csh's inability to handle its `cwd' variable across symbolic links can be used to advantage: alias cdup 'cd $cwd:h'. 2) Alternatively, one could argue to use the right tool. Pushd and popd were invented for retracing one's steps. If all you have is a hammer, everything looks like a nail. 3) However, there are real problems with attempting to reverse a symlink *in the kernel*. Foremost is that different include files would be referenced *depending on what path someone took to get to the source directory*! This is unacceptable in my mind. It is worse to reference the wrong file than to reference no file at all. 4) Robert Elz has stated that `attempting to reverse a symlink is clearly absurd'. I am in good company. 5) Symlinks are not only a means of linking across file systems, but have other uses as well, namely an easy way of making links to a directory and links to files which are renamed when edited. (Root Boy) Jim Cottrell National Bureau of Standards Flamer's Hotline: (301) 975-5688 P.S. As to why I keep calling AT&T TPC, see Barry Shein's articles for more elegant prose than I have the patience to muster. However, I will offer an example of corporate braindamage: Touch Tone. This is clearly technologically superior, easier and cheaper to process than the old pulse tone dialing. Yet instead of standardizing on this feature and improving the quality of life for everyone, certain powers saw this as a way to extract a few extra dollars from the public. And now they want us to trust in ISDN? Sheesh! The preceding opinions are mine and not those of my employer, who is prevented by law from having opinions.