zsh-workers
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: Peter Stephenson <p.stephenson@samsung.com>
Cc: zsh workers <zsh-workers@zsh.org>
Subject: Re: a bug of zsh
Date: Wed, 28 Sep 2016 17:28:08 +0200	[thread overview]
Message-ID: <CAHYJk3S_NBJCL6n24iVhhtK8MO9dfsvSgCVTSgWzTRE+QFhs+A@mail.gmail.com> (raw)
In-Reply-To: <20160928160419.4fab20f5@pwslap01u.europe.root.pri>

On Wed, Sep 28, 2016 at 5:04 PM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Wed, 28 Sep 2016 22:06:25 +0800
> ZiHan Zheng <zhengzihan1996@gmail.com> 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


  reply	other threads:[~2016-09-28 22:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20160928140702eucas1p295fe6131e7ec88107a118fa9bbcbec7e@eucas1p2.samsung.com>
2016-09-28 14:06 ` ZiHan Zheng
2016-09-28 15:04   ` Peter Stephenson
2016-09-28 15:28     ` Mikael Magnusson [this message]
2016-09-28 16:07       ` Peter Stephenson
2016-09-28 19:10         ` Bart Schaefer
2016-09-29  8:23           ` Peter Stephenson
2016-09-30  4:29             ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHYJk3S_NBJCL6n24iVhhtK8MO9dfsvSgCVTSgWzTRE+QFhs+A@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).