From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22527 invoked by alias); 14 Aug 2014 20:00:40 -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: 33009 Received: (qmail 2992 invoked from network); 14 Aug 2014 20:00:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Originating-IP: [86.6.157.246] X-Spam: 0 X-Authority: v=2.1 cv=Jul/raIC c=1 sm=1 tr=0 a=BvYiZ/UW0Fmn8Wufq9dPrg==:117 a=BvYiZ/UW0Fmn8Wufq9dPrg==:17 a=NLZqzBF-AAAA:8 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=xO9y320IWhlIvGzrs80A:9 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 Date: Thu, 14 Aug 2014 20:54:29 +0100 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: zsh 5.0.5-dev-2 Message-ID: <20140814205429.44baf512@pws-pc.ntlworld.com> In-Reply-To: <140814092045.ZM18007@torch.brasslantern.com> References: <20140812212920.67dcb116@pws-pc.ntlworld.com> <29575.1407969294@thecus.kiddle.eu> <20140814093442.1a74c5b7@pwslap01u.europe.root.pri> <20140814103227.74c7d168@pwslap01u.europe.root.pri> <140814092045.ZM18007@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 14 Aug 2014 09:20:45 -0700 Bart Schaefer wrote: > On Aug 14, 10:32am, Peter Stephenson wrote: > } Subject: Re: zsh 5.0.5-dev-2 > } > } > > Can we perhaps just remove or comment out that one error message for a > } > > release? > } > > } > zsh -fw > } > cd / > } > zsh: path expansion failed, using root directory > } > > } > We certainly need to do something. But if this is the only issue, can't > } > it be straightforwardly fixed like this? > } > } If someone can reassure me that the weird undocumented interaction with > } xbuf bypassing parameter passing starts here --- i.e. we are resetting > } xbuf here, then xsymlinks fiddles with it and this code looks at the > } result --- then I can't see how this change can be wrong as far as it > } goes. The question is, is there more to it? > > I don't have time to compose a more thorough response here, but I think > this may have been discussed in the previous thread. Yes, it says anything that resolves to the root directory has the same problem. It's entirely unclear to me from looking at xsymlinks() when an empty xbuf would actually constitute a failure. If it can't expand something as a symbolic link it simply treats it literally; and any number of ".." is valid in a path. There's no stat so it doesn't care if the path actually exists. I don't think we worry about "superroots" any more. If we don't have an answer now I'd be inclined to comment out the warning. pws