Closed SimonPilkington closed 4 years ago
For the second issue, what does echo ~ $HOME
say?
For the first, @Biswa96, any idea why wslbridge2 resolves the home directory?
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.
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.)
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?
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?
Previous wslbridge use login mode by default. To use login mode, just append a dash -
after the command line in wsltty shortcut.
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.
I reproduced the effect with Debian, but sourcing .profile does not fix it for me.
Sourcing .profile should only fix ~/bin not being added to PATH. It does not fix the current directory issue.
Now wsltty uses login shell by default. This issue may be closed.
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.
Verified. 3.1.0 does not have this issue anymore, although the issue returns as expected if a non-login shell is used.
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?
...?
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.
Closing as outdated.
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
in .profile acts as if $HOME/bin does not exist, even though it does. This also worked correctly before wslbridge2.
I am using 1809.