From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8754 invoked by alias); 19 Sep 2015 19:28:58 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36557 Received: (qmail 23049 invoked from network); 19 Sep 2015 19:28:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=A0VE+DknNNibPiQKr3+789M/pROvTwT9IeObA91As8I=; b=mXCCHpUqfsnMg/2y4//TwFsaOEbyQLLw06k0CjirWGNCk9tQx6frCviJDgsMSmLk5L XmuzVy8OjPD1i4LZSXv+MjPIJRkzG2kCDibB+ZReCz6NiLaTymMTPZML44IAmuNyKeXu 6+Ps6c0DC9T8Ihw6G5mfy5mzC585dd4qnB4vO1Uw3/s4O2/XsEhrqbL8H7oqma8j56C5 ZBbqEH2Nwq4RBTziV5E6K+za16Upn+jMN4SUY7tI9v4fE8v0k9SuUYlo4QG7grpJWrzk TJ7sIUkZ0LmMH4UAwJVKpOSKTuvaZIQpj58nl0FzGboKVz1DL3YKFPrzetTSb94Y/fJd MLBQ== X-Received: by 10.194.87.129 with SMTP id ay1mr2208055wjb.110.1442690932774; Sat, 19 Sep 2015 12:28:52 -0700 (PDT) Date: Sat, 19 Sep 2015 20:28:51 +0100 From: Stephane Chazelas To: Bart Schaefer Cc: Zsh hackers list Subject: Re: bug with $PWD in / Message-ID: <20150919192850.GB6421@chaz.gmail.com> Mail-Followup-To: Bart Schaefer , Zsh hackers list References: <20150916162630.GA6436@chaz.gmail.com> <150919110800.ZM22888@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150919110800.ZM22888@torch.brasslantern.com> User-Agent: Mutt/1.5.21 (2010-09-15) 2015-09-19 11:08:00 -0700, Bart Schaefer: > On Sep 16, 5:26pm, Stephane Chazelas wrote: > } > } It looks like zsh has a similar issue as bash as reported at: > } http://thread.gmane.org/gmane.comp.shells.bash.bugs/24162 > > How about this? > > diff --git a/Src/utils.c b/Src/utils.c > index 1de3d95..0016fa1 100644 > --- a/Src/utils.c > +++ b/Src/utils.c > @@ -692,9 +692,19 @@ ispwd(char *s) > { > struct stat sbuf, tbuf; > > - if (stat(unmeta(s), &sbuf) == 0 && stat(".", &tbuf) == 0) > - if (sbuf.st_dev == tbuf.st_dev && sbuf.st_ino == tbuf.st_ino) > - return 1; > + if (stat((s = unmeta(s)), &sbuf) == 0 && stat(".", &tbuf) == 0) > + if (sbuf.st_dev == tbuf.st_dev && sbuf.st_ino == tbuf.st_ino) { > + /* POSIX: No element of $PWD may be "." or ".." */ [...] Also, as mentioned on the bash thread: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03 SUSv4> PWD SUSv4> Set by the shell and by the cd utility. In the shell the value SUSv4> shall be initialized from the environment as follows. If a value SUSv4> for PWD is passed to the shell in the environment when it is SUSv4> executed, the value is an absolute pathname of the current working SUSv4> directory that is no longer than {PATH_MAX} bytes including the SUSv4> terminating null byte, and the value does not contain any SUSv4> components that are dot or dot-dot, then the shell shall set PWD SUSv4> to the value from the environment. Otherwise, if a value for PWD SUSv4> is passed to the shell in the environment when it is executed, the SUSv4> value is an absolute pathname of the current working directory, SUSv4> and the value does not contain any components that are dot or SUSv4> dot-dot, then it is unspecified whether the shell sets PWD to the SUSv4> value from the environment or sets PWD to the pathname that would SUSv4> be output by pwd -P. Otherwise, the sh utility sets PWD to the SUSv4> pathname that would be output by pwd -P. In cases where PWD is set SUSv4> to the value from the environment, the value can contain SUSv4> components that refer to files of type symbolic link. In cases SUSv4> where PWD is set to the pathname that would be output by pwd -P, SUSv4> if there is insufficient permission on the current working SUSv4> directory, or on any parent of that directory, to determine what SUSv4> that pathname would be, the value of PWD is unspecified. SUSv4> Assignments to this variable may be ignored. If an application SUSv4> sets or unsets the value of PWD, the behaviors of the cd and pwd SUSv4> utilities are unspecified. So, the should recompute $PWD if the one it gets from the environment is a relative path (it's not only about . or .., think of symlinks). -- Stephane