cd:cd:13 in Cygwin root

[ghost]

If I do the following commands:

cd /
cd home

I get

cd:cd:13: no such file or directory: home

If I run

unfunction cd

I get

cd: no such file or directory: home

I can do

cd /home
cd ./home
cd ..

and I can cd elsewhere

This is on Cygwin x86_64 and zsh 5.0.6. Even with bin, lib in root this doesn't work.

I will test later on Fedora 21 x86_64.

[ghost]

On Fedora 21 x86_64 (Red Hat GNU) with zsh 5.0.7 this issue is not present.

[mcornella]

What's the output of ls -l /? What about cd /; ls -l?

[ghost]

I'm in Linux ATM but ls -l / and cd / then ls -l give the same results. pwd gives /. builtin cd home doesn't work either. home is sticky but bin and lib aren't.

[ghost]

Without oh-my-zsh it works fine.

[mcornella]

What do you mean "home is sticky"? Can you post the output of ls -lF /?

[ghost]

home has the sticky flag like tmp. But this is irrelevant because bin and lib don't work either.

[apjanke]

I can reproduce, on my Windows 7 x64 machine running Cygwin and oh-my-zsh. All three are up to date as of 2/14/2015.

When in /, attempting to cd to any of its subdirs (bin, tmp, etc) using a relative path causes cd to sit for several seconds, and then fail with a cd: no such file or directory: <name> error.

[@ in /]
$ cd bin
cd: no such file or directory: bin
[✘ @ in /]
$ cd cygdrive
cd: no such file or directory: cygdrive
[✘ @ in /]
$ cd dev
cd: no such file or directory: dev

It doesn't happen when I am not running OMZ. If I disable OMZ, doing cd /; cd bin works normally.

Doesn't appear to be related to shell options. I used setopt to get back to a minimal set after OMZ set them up; still happening.

[apjanke]

Looks like it's something to do with $cdpath, which is normally () but OMZ sets to (.).

If I set $cdpath back to (), the problem goes away.

[@ in ~]
$ cd /
[@ in /]
$ set | grep -a cdpa
cdpath=(.)
[@ in /]
$ cd home
cd: no such file or directory: home
[✘ @ in /]
$ cdpath=()
[@ in /]
$ cd home
[@ in /home]
$

It is being set in lib/completion.zsh at line 37. Does the autocomplete actually need . explicitly in the cdpath to work right?

# disable named-directories autocompletion
zstyle ':completion:*:cd:*' tag-order local-directories directory-stack path-directories
cdpath=(.)

I don't think it does, since it has local-directories in there ahead of path-directories, and local-directories ignores $cdpath and just looks under pwd.

[ghost]

Nice. cdpath only sets where cd is relative. For example

cdpath=(/)
cd ~
rm -rf lib
cd lib
pwd

/lib

So setting it to the current directory makes no sense. Anyway, I don't use OMZ so it isn't my problem.

[apjanke]

"OMZ" is just a short abbreviation for "oh-my-zsh". Are you still using oh-my-zsh and encountering this problem?

[apjanke]

I think we may have found a bug in ZSH itself. The intent is clearly for . in cdpath to behave the same as the implicit no-prefix dir when it's absent. But in zsh's cd implementation (in Src/builtin.c in the ZSH distribution), they go down different code paths, which intersect differently with Cygwin-specific escaping code. It looks like in the case of the explicit ., the Cygwin escaping of / is bypassed, naive path concatenation happens and the internal effective path is //bin, which on Unix is just an alias for /bin, but on Windows is a UNC path that might go looking for a server named bin. And that's why it takes so long to return the error; it's waiting on a network timeout to see if it can find the host. (And the error message is constructed using the original command argument, not that internal path.)

I'll report this to the ZSH maintainers and see what they think. In the mean time, we could work around it in oh-my-zsh by doing cdpath=() instead of cdpath=(.), or just removing it entirely. I lean toward removing it, since it's more of a user preference or network context thing; the default is already (), and if it's set to something else, there's maybe a good reason for it.

Hey, @kremso, it looks like you added the code to lib/completion.zsh that does cdpath=(.) back in 74b2c5d (for #80, I think). Was there a particular reason for explicitly including the . in it? Any concerns with removing it?

[mcornella]

Just checking in to say, @apjanke, that you're doing a lot of work and I'll catch up with it later this week.

Thanks for your outstanding work, I really appreciate it 😄

[apjanke]

Thank you and you're welcome! I decided to buckle down and really learn about shells and terminals this year, and what better way to do it than actually working with them?

[ghost]

No, I no longer use oh-my-zsh. I use Powerline and have gone back to my custom made zshrc.

[ghost]

@apjanke Is this your patch?

[kremso]

@apjanke I don't really remember if cdpath=(.) was essential for what I was doing, but by reading the associated pull request, it seems that testing it should be trivial. Just remove the cdpath (or set it back to ()) and try if autocompletion offers some "weird" completion entries.

[apjanke]

@saleemrashid1 - I didn't write the code (I don't have the guts to be mucking around inside path normalization C code inside a shell), but yeah, it's in response to the bug report I sent to zsh-workers about this issue.

[ghost]

That's good.

[apjanke]

Created Pull Request #3550, which removes the $cdpath=(.), leaving it as its default (). (I don't know why the PR isn't automatically showing up as "referenced" in this issue here.)

I've played around with the autocompletion like @kremso suggests and it seems fine. Could use some more eyes. I can't figure out how to put a "Testers Needed" tag on #3550. Can someone do so, or let me know how I can do it?

[ghost]

#3597

https://help.github.com/articles/applying-labels-to-issues-and-pull-requests/

[apjanke]

Looks like I just don't have permissions to use labels on issues in the oh-my-zsh repo.

[mcornella]

Looks like I just don't have permissions to use labels on issues in the oh-my-zsh repo.

We don't. But it has been suggested: #2771. EDIT (to clarify): only Robby has permissions to do so.