Do not resolve symlinks and especially hard links and bind mounts for --cwd and cwd

[op3]

Is your feature request related to a problem? Please describe.
A new spawned window, tab or pane will inherit the cwd. It can also be supplied directly using the --cwd option of e. g. wezterm cli spawn, etc. To support relative paths (see f3a2e84 and #1243), wezterm canonicalizes the cwd. The current implementation does not only resolve relative paths, but also follows symlinks, and even worse, hard links and bind mounts.

Resolving symlinks seems questionable, I can imagine plenty of use cases where a user would prefer to work in the symlinked directory and not at the canonicalized path.

However, resolving bind mounts completely breaks with my setup: I am using systemd-homed, which in my case is bind-mounting /home/$USER.homedir owned by nobody to /home/$USER. Using ID-mapping, the bind-mounted /home/$USER is mapped to my user ID, such that I can access it. I do not have the rights to access /home/$USER.homedir, and even if I had, the owner and groups of all files/directories would be wrong. Whenever I open a new tab (or similar), and I am in a subdirectory of my $HOME, wezterm will redirect me to the /home/$USER.homedir equivalent, and suddenly I am dropped into a directory which I do not have the rights to access.

(Interestingly, wezterm cli spawn --cwd /home/$USER.homedir/Downloads will result in ERROR wezterm > Permission denied (os error 13); terminating, but wezterm cli spawn --cwd /home/$USER/Downloads will happily drop me in /home/$USER.homedir/Downloads.)

Describe the solution you'd like
Wezterm should only resolve relative paths, probably not symlinks, and definitely not hard links and bind mounts.

Describe alternatives you've considered
Maybe resolving symlinks is desired behavior (probably not), and only resolving hard links/bind mounts is undesired.

Additional context
…

[wez]

This should be fixed now in main.

It typically takes about an hour before fixes are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[op3]

It’s working in main, thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.