/-happy
Doug Gwyn
gwyn at smoke.BRL.MIL
Sat Aug 18 04:57:18 AEST 1990
In article <3139 at dftsrv.gsfc.nasa.gov> merritt at 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.
More information about the Comp.unix.questions
mailing list