Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: /-happy
Message-ID: <13609@smoke.BRL.MIL>
Date: 17 Aug 90 18:57:18 GMT
References: <3139@dftsrv.gsfc.nasa.gov>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 22

In article <3139@dftsrv.gsfc.nasa.gov> merritt@iris613.gsfc.nasa.gov (John H Merritt) writes:
>Explain why '/////' is valid in the following statement:
>cd /./../tmp/////../././bin
>It is interesting that any permutation of '.', '..', '/' and directory
>names can be used with, at least, csh, sh, and tcsh to yield a valid
>path name.

You're overgeneralizing.
Shells, which must necessarily implement "cd" as a built-in instead of
invoking a subprocess to do the chdir, sometimes are implemented to keep
track internally of the current working directory, especially if they
offer a shell variable that expands to the CWD string.  As a side-effect
of an internal canonicalization of the CWD string, such shells may
themselves try to remove . .. and null pathname components.  It is not
true that the kernel would necessarily accept such a noncanonicalized
string as a valid argument to the chdir() system call.
All the pathname canonicalization algorithms I've encountered so far
have had some undesirable features, such as you mention.  I've been
working on an improved algorithm, but it's not available yet.  Note that
there is no way to handle "whatever/foo/.." where "foo" does not exist
or is not a directory, without consulting the kernel about it, which is
contrary to the whole notion of using pathname canonicalization.