mintty / wsltty

Mintty as a terminal for Bash on Ubuntu on Windows / WSL
Other
3.12k stars 104 forks source link

Symlinked home directory seems to be handled incorrectly since wslbridge2 #205

Closed SimonPilkington closed 4 years ago

SimonPilkington commented 5 years ago

I have my home directory symlinked to a location outside the WSL filesystem. This worked fine until wsltty started using wslbridge2; now the symlink is apparently resolved, and thus I end up in the symlink destination instead of ~ when starting wsltty.

Moreover

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
     PATH="$HOME/bin:$PATH"
fi

in .profile acts as if $HOME/bin does not exist, even though it does. This also worked correctly before wslbridge2.

I am using 1809.

mintty commented 5 years ago

For the second issue, what does echo ~ $HOME say? For the first, @Biswa96, any idea why wslbridge2 resolves the home directory?

SimonPilkington commented 5 years ago

echo ~ $HOME produces identical results (the home directory as set in passwd) as expected. The incorrect result is only produced during startup. If I . .profile after startup, it works correctly. I believe both issues are the same issue.

SimonPilkington commented 5 years ago

Unfortunately I see no changes with the patch applied.

I did some testing, and a login shell does not have the issue. That is .\wslbridge2.exe -l -W ~ works correctly while .\wslbridge2.exe -W ~ has the issue as described.

(Using a login shell solves both issues.)

mintty commented 5 years ago

The next wsltty release shall use login mode anyway. However, it would still be interesting to identify the cause. You said . .profile does the adjusting. Can you track step-by-step which of the commands in .profile does it effectively, please? Do you have a cd in there?

SimonPilkington commented 5 years ago

Actually, I just remembered .profile is not executed for non-login shells, so if wsltty currently doesn't spawn a login shell, this is the expected result. Yet it worked before the switch to wslbridge2, which would indicate wsltty spawned a login shell then. Can you confirm this?

Biswa96 commented 5 years ago

Previous wslbridge use login mode by default. To use login mode, just append a dash - after the command line in wsltty shortcut.

SimonPilkington commented 5 years ago

Okay, mystery solved, although we don't know why non-login shells have trouble with symlinked home directories. It could also be a problem in bash I suppose. Feel free to close this issue if you believe it is unrelated to wsltty or wslbridge2.

mintty commented 5 years ago

I reproduced the effect with Debian, but sourcing .profile does not fix it for me.

SimonPilkington commented 5 years ago

Sourcing .profile should only fix ~/bin not being added to PATH. It does not fix the current directory issue.

Biswa96 commented 5 years ago

Now wsltty uses login shell by default. This issue may be closed.

mintty commented 5 years ago

To be verified. In addition to the statement above

don't know why non-login shells have trouble with symlinked home directories

I would not know why login shells should not have the same trouble.

SimonPilkington commented 4 years ago

Verified. 3.1.0 does not have this issue anymore, although the issue returns as expected if a non-login shell is used.

mintty commented 4 years ago

It might be interesting to find the cause, still. Which shell do you use? What if you use another shell? If you start non-login, facing the effect, and source .profile, what happens? ...?

SimonPilkington commented 4 years ago

Shell is whatever bash version is packaged in Debian testing. I talked about sourcing .profile above. I might try another shell sometime to see what happens. I don't have time right now.

mintty commented 4 years ago

Closing as outdated.