Discussion of POSIX "cd" changes from austin-group

[Bart Schaefer <schaefer@xxxxxxxxxxx>]

I don't know if anyone else is following this stuff any more, but this is
probably relevant to zsh.  I *think* zsh already has the behavior of first
trying to cd based on $PWD and then trying again with a literal path if
that fails, so it avoids the bug noted by Andries Brouwer -- but not in
the way that the proposed aardvark would require.

Visit the austin-group archives for the full thread, this is just the tail
of the thread so far.  I'm pointing this out now rather than wait for the
actual aardvark because I'll be away from email for a while starting the
end of this week.

I guess it's just as well I've never gotten around to rewriting the guts
of bin_cd().


---------- Forwarded message ----------
Date: Mon, 10 May 2004 17:21:05 +0100
From: Geoff Clare <gwc@xxxxxxxxxxxxx>
To: austin-group-l@xxxxxxxxxxxxx
Subject: Re: cd, relative paths, and PATH_MAX
Resent-Date: 10 May 2004 16:21:33 -0000
Resent-From: austin-group-l@xxxxxxxxxxxxx
Resent-To: austin-group-l@xxxxxxxxxxxxx

Based on the discussion so far, I have made a first attempt at some
editing instructions to go in an aardvark.  They include a fix for the
problem that Chet identified in step 8.

Any comments?

Action:

Replace step 7 with the following:

    "7.  If the -P option is in effect, proceed to step 9."

(Note that most of the old step 7 text reappears in the new step 10
below.)

Replace step 8b with the following:

    "b.  For each dot-dot component, if there is a preceding component
         and it is neither root nor dot-dot, then:

	   i.  If the preceding component does not refer (in the
	   context of pathname resolution with symbolic links followed)
	   to a directory, then the cd utility shall display an
	   appropriate error message and no further steps shall be
	   taken.

	   ii. The preceding component, all slashes separating the
	   preceding component from dot-dot, dot-dot and all slashes
	   separating dot-dot from the following component (if any)
	   shall be deleted."

Insert a new step 9:

    "9.  If curpath is longer than {PATH_MAX} bytes (including the
	 terminating null) and the directory operand was not longer
	 than {PATH_MAX} bytes (including the terminating null), then
	 curpath shall be converted from an absolute pathname to an
	 equivalent relative pathname if possible.  This conversion
	 shall always be considered possible if the value of PWD is
	 an initial substring of curpath.  Whether or not it is
	 considered possible under other circumstances is
	 implementation-dependent."

Replace the old step 9 with the following:

    "10. The cd utility shall then perform actions equivalent to the
	 chdir() function called with curpath as the path argument.
	 If these actions fail for any reason, the cd utility shall
	 display an appropriate error message and the remainder of
	 this step shall not be executed.  If the -P option is not in
	 effect, the PWD environment variable shall be set to the
	 value that curpath had on entry to step 9 (i.e. before
	 conversion to a relative pathname).  If the -P option is in
	 effect, the PWD environment variable shall be set to an
	 absolute pathname for the current working directory and shall
	 not contain filename components that, in the context of
	 pathname resolution, refer to a file of type symbolic link.
	 If there is insufficient permission on the new directory, or
	 on any parent of that directory, to determine the current
	 working directory, the value of the PWD environment variable
	 is unspecified."

-- 
Geoff Clare <g.clare@xxxxxxxxxxxxx>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England



---------- Forwarded message ----------
Date: Tue, 11 May 2004 10:10:21 +0100
From: Geoff Clare <gwc@xxxxxxxxxxxxx>
To: austin-group-l@xxxxxxxxxxxxx
Subject: Re: cd, relative paths, and PATH_MAX
Resent-Date: 11 May 2004 09:10:44 -0000
Resent-From: austin-group-l@xxxxxxxxxxxxx
Resent-To: austin-group-l@xxxxxxxxxxxxx

Seeds, Glen <Glen.Seeds@xxxxxxxxxx> wrote, on 10 May 2004:
>
> "Whether or not it is considered possible under other circumstances is
> implementation-dependent."
> 
> Available options here are "implementation defined" or "unspecified".

Thanks.  On re-reading step 9 I see that there is a problem with the
"substring" condition.  It would require conversion if, for example,
PWD is "/home/user1" and curpath is "/home/user12345/something".
I have also realised that just saying it can be considered possible
does not affect the length condition in the way that I had intended.

I have changed "implementation-dependent" to "unspecified", fixed
the substring condition, and added a new sentence on the end about
the length condition.  The new step 9 in full is:

    "9.  If curpath is longer than {PATH_MAX} bytes (including the
	 terminating null) and the directory operand was not longer
	 than {PATH_MAX} bytes (including the terminating null), then
	 curpath shall be converted from an absolute pathname to an
	 equivalent relative pathname if possible.  This conversion
	 shall always be considered possible if the value of PWD, with
	 a trailing slash added if it does not already have one, is an
	 initial substring of curpath.  Whether or not it is
	 considered possible under other circumstances is unspecified.
	 Implementations may also apply this conversion if curpath is
	 not longer than {PATH_MAX} bytes or the directory operand was
	 longer than {PATH_MAX} bytes."

-- 
Geoff Clare <g.clare@xxxxxxxxxxxxx>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England



---------- Forwarded message ----------
Date: Tue, 11 May 2004 14:49:27 +0100
From: Geoff Clare <gwc@xxxxxxxxxxxxx>
To: austin-group-l@xxxxxxxxxxxxx
Subject: Re: cd, relative paths, and PATH_MAX
Resent-Date: 11 May 2004 13:49:47 -0000
Resent-From: austin-group-l@xxxxxxxxxxxxx
Resent-To: austin-group-l@xxxxxxxxxxxxx

Andries Brouwer <Andries.Brouwer@xxxxxx> wrote, on 11 May 2004:
>
> > > Suppose the current working directory has a subdirectory abc,
> > > and I want to change the current working directory there, what do I do?
[snip]
> > use "cd ./abc" and make sure that you don't ever set PWD directly
> > (or unset it).
> 
> No, that is not the right answer.
> What sometimes happens is that some directory lower in the tree
> gets renamed. So I do not touch PWD, and the inode that is my
> current working directory does not change, but PWD no longer
> is a pathname that points to it.

Okay, I see the problem now.

Since cd's logical directory handling is fundamentally dependent on
PWD, I think the answer you want ought to be "cd -P ./abc".  However,
the spec doesn't currently require that to work.  (Nor would my
proposed modified text, in its current form.)

The simplest fix would be for the new step 9 to require that
conversion back to a relative path is always done if the -P option
is in effect.  A more elegant fix might be not to convert to an
absolute path in the first place when -P is in effect.  I.e. with -P,
step 6 would set curpath to the operand and step 9 would be skipped.
In the latter case an implementation could still do a conversion
to absolute path and back to relative (like ksh does), as the
behaviour seen by applications (or interactive users) would be the
same.

Unless someone can suggest a reason for preferring the simpler fix,
I'm inclined to go for the more elegant one.

-- 
Geoff Clare <g.clare@xxxxxxxxxxxxx>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England