scs@seismo.CSS.GOV (06/28/87)
[[When reading this, please bear in mind that I missed the original
Korn article which precipitated the discussion]]
In the midst of all of this discussion of symbolic links and the meaning
of 'cd' and 'pwd', the meaning of '..' seems to have become center stage.
Here are some statements which I think we all agree on:
1. '..' is the name of a file in your current directory whose
inode number indicates the parent of the current directory;
with 'parent' admittedly being defined loosely.
2. The general usage of the shell command 'cd ..' is to return
to the last-but-one directory on the path which got you into
your current directory.
3. The 'cd X' means 'change the current working directory to X'.
Given the use of symbolic links (and even given the /etc/mount command,
to some degree) (2) and (3) are incompatible. As best I can tell, the
question then becomes what should 'cd ..' do. My vote [[for what it's
politically worth :-) ]] is that 'cd ..' should always mean the parent
directory, not 'one step backwards on the path taken'. Cd has a clear
and specific meaning. If you want to back up one, fine: let's add
a 'pb' for 'path backwards' command, and a count to indicate how
many levels (so that 'pb 2' is equivalent to 'cd ../..' but takes into
account symbolic links). UNIX already has too damn many 'special cases'
in commands. Let's not add another just for the people who haven't
thought through what the file named '..' really is. Folks are (by
usage) treating 'cd ..' as if it were some magic. It ain't, and lets
not try to inject any just so symbolic links will work like hard links.
There are already too many places where symlinks differ in usage. Lets
not further confuse symlinks with hardlinks by adding weird special
cases in the shells (or worse, the kernal). Better by far to have
a simple new command to do a simple new thing.gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/29/87)
In article <8075@brl-adm.ARPA> umix!itivax!lokkur!scs@seismo.CSS.GOV (Steve Simmons) writes: >Here are some statements which I think we all agree on: You should know better than that! > 1. '..' is the name of a file in your current directory whose > inode number indicates the parent of the current directory; > with 'parent' admittedly being defined loosely. No, these days there is no particular reason to expect inode numbers to be associated with directory entries or to have simple meaning; nor do all directories have actual entries for ".." and ".". Even in the "good old days" of simple UNIX filesystems (around 7th Ed.), ".." had special properties in the root of a mounted filesystem. > 2. The general usage of the shell command 'cd ..' is to return > to the last-but-one directory on the path which got you into > your current directory. People are arguing about this, so I don't think "we all agree" on it. > 3. The 'cd X' means 'change the current working directory to X'. That is a tautology. What is meant by that phrase, operationally? >If you want to back up one, fine: let's add >a 'pb' for 'path backwards' command ... Most of the discussion centers on semantics for the chdir() system call; the "cd" shell command is used just for notational convenience. >Let's not add another just for the people who haven't >thought through what the file named '..' really is. Ahem, some of the folks on Korn's side have given considerable thought to this matter. As undoubtedly have some of the som l), ot
jdb@mordor.s1.gov (John Bruner) (07/02/87)
> Most of the discussion centers on semantics for the chdir() system > call; the "cd" shell command is used just for notational convenience. 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. The "trapdoor" feature may or may not be a "good thing" -- I don't have strong opinions on that subject. However, inconsistent interpretations of pathnames between programs on the same machine only creates unnecessary confusion. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!seismo!mordor!jdb (415) 423-4848
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/05/87)
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.
gamiddleton@orchid.UUCP (07/06/87)
In article <6054@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > 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. > > ... 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). We have a modified shell here, which finds the real pathname of the current directory, to avoid confusion. It matters where you are, not how you got there: Orc % ls -l /sys lrwxr-xr-x 1 root 11 Apr 24 19:52 /sys -> usr/src/sys Orc % pushd /sys /usr/src/sys ~ Orc % pwd /usr/src/sys Orc % pushd .. /usr/src /usr/src/sys ~ __ -Guy Middleton, University of Waterloo MFCF/ICR, gamiddleton@watmath
jdb@mordor.s1.gov (John Bruner) (07/06/87)
I periodically must explain to users why the pathname "~/.login" (for example) isn't understood by most of the programs that they use. I do not want to explain why "../foo" means one thing to the shell (or, worse yet, one of the shells) and another thing to their favorite editor or other utility. If the semantics of ".." are to be changed, the proper place for the change is the kernel, not in some (but, inevitably, not all) user-level programs. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!seismo!mordor!jdb (415) 423-4848
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/08/87)
In article <14336@mordor.s1.gov> jdb@mordor.UUCP (John Bruner) writes: >If the semantics of ".." are to be changed, the proper place for >the change is the kernel, not in some (but, inevitably, not all) >user-level programs. That is quite correct. My point is that the disagreement in semantics (caused by the shells having special .. code) originated when people found that the kernel behavior posed a practical problem at the user level. This would argue that it is not appropriate at the application program, i.e. system call, level either. Indeed, Korn's proposal was to adapt kernel handling of .. when symlinks are added to UNIX System V (note that this is different from "changing the current semantics", since that situation doesn't currently arise), in which case the special stuff in shells could be removed. I haven't found much problem in practice brought on by the semantic discrepancy, since (as I noted earlier) one has to be thinking rather weirdly to set up directory symlinks in such a way that ../foo pathnames fed to an editor etc. would be affected by the semantic difference. The usual human/program use of such pathnames is to reach a different node in the tree when the absolute root name is not known or is relatively inconvenient to specify. Other nodes are usually accessed by full absolute pathnames (irrespective of whether symlinks are traversed in those pathnames). Under normal civilized use of symlinks, both name specification modes don't .. through a symlinked point. It's probably worth noting that more radical reorganizations of the UNIX notion of directory-based filesystems could moot this whole issue.