From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18169 invoked by alias); 28 Sep 2016 22:37:59 -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: 39487 Received: (qmail 5053 invoked from network); 28 Sep 2016 22:37:59 -0000 X-Qmail-Scanner-Diagnostics: from mail-qt0-f175.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.216.175):SA:0(1.1/5.0):. Processed in 0.35713 secs); 28 Sep 2016 22:37:59 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=DATE_IN_PAST_06_12, FREEMAIL_FROM,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.216.175 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SZMCcH/Lb+wyhHjGlaUwXGO7Izv9w6Ho+ZY8tyb2GWQ=; b=A6vJqck8IbExwlNLGF5zXiZckP2FDCoGHKGRCfGkwxD7fO5yVjx6HXct6tg91qWliy +NTtzoFbA4r8DDoUkF3pKOY8I8orVbK5gwcI+g1LLfi9fZzFjFbsrcbbKkYtE6OolTU4 UgE1U5xNxCvSc+EhLNQiMnS0CXccMF+aFJDS643PTN2+DaD00NPND9UifBCceVn1iFJ+ Km317NUbw2NA3o6v4bZzbwMX2LUkFluDTmk/xzWeaRMgJHn3E5NbNSBw87aW0R6qa3dQ xgRwUWtCn65hBGG3uTCicvbph5usTprDPhxTRFN0Ec02hIbPR2Mkus0jzMSbZnDEOi5f t6Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SZMCcH/Lb+wyhHjGlaUwXGO7Izv9w6Ho+ZY8tyb2GWQ=; b=eLJIV5PYJoPH+Y4uYhv/70NqcMBM6GbsZvNv2dDLDaETG5pWmcuy+XSk/XmCVEDd1H XUI2FY1WKiSVqIFjaIQ7/niJuj9Gt/KhL/bk3lOFKd+k0wHaol/E0P46u7NeoJ7cOF12 sR7GkabwqW8y1cRKYawhDGsIxwYwzBWWFavqB8xrucli5z1HobjOCrdkUbXRUS16jBFH WuvvZOYeSRWJjWwlHIVltzWJYtzxlOak9/MIqFiW/XOVN2BIBS3CX7YBvVVaoBtA9rsR 2jNGlmRbo21ctV2EbA4RBd5nZDBUf7oXxyn/0B0paZsq9hsANFh84hTsh9J4hmPevS16 wc/A== X-Gm-Message-State: AA6/9RnhJHXqUS9LvkZbrrLBE4xqvAhWdAoCdzhg0qorPjTxqe7bAA525ac71XmleBG0FHjQ+8nU/D2h6LKgyA== X-Received: by 10.200.40.91 with SMTP id 27mr33877008qtr.46.1475076489451; Wed, 28 Sep 2016 08:28:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160928160419.4fab20f5@pwslap01u.europe.root.pri> References: <20160928160419.4fab20f5@pwslap01u.europe.root.pri> From: Mikael Magnusson Date: Wed, 28 Sep 2016 17:28:08 +0200 Message-ID: Subject: Re: a bug of zsh To: Peter Stephenson Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On Wed, Sep 28, 2016 at 5:04 PM, Peter Stephenson wrote: > On Wed, 28 Sep 2016 22:06:25 +0800 > ZiHan Zheng wrote: >> to reproduce this bug: >> >> cd ~ >> mkdir aaa >> cd aaa >> rm ~/aaa -r >> cd . >> >> then current working directory is just "." and you can do nothing until cd >> into an absolute path. > > Hmmm... I can see you're point, I think --- before you do "cd .", the > shell will happily use the logical directory structure to e.g. "cd ..", > whereas after you do "cd ." you're stuck without something like cd > $PWD/.. > > It would certainly be good if there's some way of aborting the "cd ." > consistently so we both don't actually change directory and don't lose > state. I think the problem may be once we find we can't cd any more we > throw up our hands in horror and decide we don't know where we are, > which is certainly a bit feeble, particularly since there's no > outward indication of a problem until you find you're trapped. > > Is there some reason we can't just stat the directory first and bail > out early? I know it's prohibitively expensive testing glob results > with stat, but this is a rather different case. > > However, the cd logic is already more complicated than you would > probably believe, and changing to a directory that no longer exists > isn't going to have good effects, so I'm not sure how much sleep we're > (well, I'm) actually going to lose over this, to be brutally honest. FWIW this is only a problem if you use nochasedots/nochaselinks, which while it is the default, is overall a very confusing option to have set and hopefully most people disable it. In either case you can always do cd -P .. to get out as well. I feel like it should be possible to get the -L branch to detect this state and fall back to a -P .. but honestly I'm not sure if the current state is unintended for -L or not. -- Mikael Magnusson