Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: .. not considered as a botch Message-ID: <6054@brl-smoke.ARPA> Date: Sat, 4-Jul-87 21:33:48 EDT Article-I.D.: brl-smok.6054 Posted: Sat Jul 4 21:33:48 1987 Date-Received: Sun, 5-Jul-87 02:54:10 EDT References: <8075@brl-adm.ARPA> <6037@brl-smoke.ARPA> <13640@mordor.s1.gov> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 31 In article <13640@mordor.s1.gov> jdb@mordor.UUCP (John Bruner) writes: >I am disturbed by discussions of changes to the shell ("tcsh" and >"ksh", for example) which apparently cause the shell to interpret ".." >in a different way than the kernel does. .... inconsistent >interpretations of pathnames between programs on the same machine only >creates unnecessary confusion. WRONG! Consider why so many shells (including the BRL version of the SVR2 Bourne shell that I maintain) have been modified to act this way; it's not that the shell maintainers had nothing better to do. In my case, I have font files and so forth scattered among several disks, and furthermore the particular actual partition names and packaging are different on different systems, so I use symlinks to create the identical directory hierarchical structure on all systems (it looks like it's all on one filesystem). Now, after getting into the wrong place one too many times by "cd ..", I got sufficiently motivated to make this behave in an UNCONFUSING, expected way. I don't even have a run-time option in my shell to get the old "cd .." behavior, and I have never missed it (except occasionally in a positive sense when I reflect on how well the new scheme works by comparison). I have a hard time imagining a practical situation where there would be a problem with the kernel handling .. pathname components the way that my shell handles "cd ..". One would have to have a symbolic link to a BRANCH of a source tree whose header files were in a parallel branch, or some similar situation. That is a pretty dumb way to set up symbolic links to sources; one should treat the source tree as an integral object rather than link into the middle of it. If the sources have to spread across several partitions using symlinks, then you're in the situation I described above in which the Korn approach to .. is the only sane one.