Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!adm!umix!itivax!lokkur!scs@seismo.CSS.GOV
From: scs@seismo.CSS.GOV
Newsgroups: comp.unix.wizards
Subject: .. not considered as a botch
Message-ID: <8075@brl-adm.ARPA>
Date: Sun, 28-Jun-87 03:08:05 EDT
Article-I.D.: brl-adm.8075
Posted: Sun Jun 28 03:08:05 1987
Date-Received: Sun, 28-Jun-87 09:42:50 EDT
Sender: news@brl-adm.ARPA
Lines: 32

[[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.