From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22030 invoked from network); 11 May 2004 14:48:47 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 11 May 2004 14:48:47 -0000 Received: (qmail 30791 invoked from network); 11 May 2004 14:48:28 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 May 2004 14:48:28 -0000 Received: (qmail 25208 invoked by alias); 11 May 2004 14:48:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19918 Received: (qmail 25199 invoked from network); 11 May 2004 14:48:22 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 11 May 2004 14:48:19 -0000 Received: (qmail 30374 invoked from network); 11 May 2004 14:48:19 -0000 Received: from unknown (HELO moonbase.zanshin.com) (root@167.160.213.139) by a.mx.sunsite.dk with SMTP; 11 May 2004 14:48:15 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i4BEm1QK010421 for ; Tue, 11 May 2004 07:48:01 -0700 Date: Tue, 11 May 2004 07:47:56 -0700 (PDT) From: Bart Schaefer To: zsh-workers@sunsite.dk Subject: Discussion of POSIX "cd" changes from austin-group Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 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 To: austin-group-l@opengroup.org Subject: Re: cd, relative paths, and PATH_MAX Resent-Date: 10 May 2004 16:21:33 -0000 Resent-From: austin-group-l@opengroup.org Resent-To: austin-group-l@opengroup.org 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 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 To: austin-group-l@opengroup.org Subject: Re: cd, relative paths, and PATH_MAX Resent-Date: 11 May 2004 09:10:44 -0000 Resent-From: austin-group-l@opengroup.org Resent-To: austin-group-l@opengroup.org Seeds, Glen 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 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 To: austin-group-l@opengroup.org Subject: Re: cd, relative paths, and PATH_MAX Resent-Date: 11 May 2004 13:49:47 -0000 Resent-From: austin-group-l@opengroup.org Resent-To: austin-group-l@opengroup.org Andries Brouwer 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 The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England