Repository navigation
Symlinks cause weirdness related to trailing slash #1775
Description
I found that tab expansion doesn't work in a symlinked folder. Investigation found that the shell can't see ANY items in the $PWD, but /something/ causes things to right themselves in the same session.
Steps to reproduce
cd /tmp
mkdir test1
mkdir test1/foo
mkdir test1/bar
ln -s test1 test2 # using /bin/ln here
dir test1 # "case A"
dir test2 # "case B"Expected behavior
Output from case A should equal case B, but the "Directory name" should read "/tmp/test2".
Actual behavior
Case B shows only the file entry of the symlink. That would be ok in some cases, HOWEVER what you see is that this behavior affects lots of things like tab expansion. For example, to continue repro:
cd test2
cd [TAB] # nothing happens with any tab completion commands hereNote that you can get around some of the issues by manually appending a forward-slash. e.g. dir test2/.
Environment data
OSX 10.11.6
Name Value
---- -----
PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.8
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Activity
halr9000 commentedon Aug 12, 2016
I should add that after some poking around, sometimes the problem seems to resolve itself. I have not yet figured out what is happening to cause this.
andyleejordan commentedon Aug 17, 2016
Agreed; bug reproduces. Listing the symlink should not require a trailing slash.
joeyaiello commentedon Mar 20, 2017
This may be related to #2865
SteveL-MSFT commentedon Apr 19, 2017
Chunqing Chen (@chunqingchen) can you validate if your PR for the related issue fixes this and if we need to add a test case for this issue?
1 remaining item
SteveL-MSFT commentedon May 2, 2017
Still repros with #2974
chunqingchen commentedon May 18, 2017
Steve Lee (@SteveL-MSFT) Joey Aiello (@joeyaiello)
I used to be able to repro it on ubunto 14.04
Now I test the scenario on both macos 10.12.4 and ubunto 16.04 and it passes. (Thanks to my machine crash i have to reinstall everything)
It seems this bug is OS version related but not powershell version related (the default powershell installed from ./tools/download.sh also passes).
Shall we set this bug as not repro?
SteveL-MSFT commentedon May 18, 2017
This isn't repro'ing for me with beta1. Looks like it was fixed with another change.