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.