change cd to handle not readable directories: chdir+open instead of open+fchdir

[TheJonny]

The previous code for the cd builtin used open(.., O_RDONLY) + fchdir to change the working directory. This fails, if the user has no read permission on the directory (but has the x permission). Now we first chdir and then try to open the new workin directory. this might fail, but in this case cd was already successful.

The alternative would be to use O_PATH instead of O_RDONLY, but this is not portable. As an improvement, we could use O_PATH for supported platforms later.

Fixes issue #10432

TODOs:

• Changes to fish usage are reflected in user documentation/manpages. (from the template, i think it does not apply here)
• Tests have been added for regressions fixed
• User-visible changes noted in CHANGELOG.rst
• Check for / discuss now unused code

[TheJonny]

should we note the change in CHANGELOG.rst?
should we drop fds::wopen_dir (now unused) or keep it for future use?

[TheJonny]

The failed test is from the additional stderr line, from the testcase below.
Unable to open the current working directory: Permission denied
Do we want this output in cd?
also without this patch mkdir a; chmod -r a; sh -c 'cd a; fish' triggers this message

[ridiculousfish]

Thank you for the PR. The reason we store the file descriptor in the parser is that subprocesses will be implemented using multiple threads, each with their own fd for the cwd. For that reason we should not rely on the processes's implicit cwd (i.e. chdir) for anything, outside of startup, where we discover where we are.

That said, I would definitely like to see this fixed. I'm fine with using O_PATH on Linux (supported since 2014), and O_SEARCH / O_EXEC on BSDs / macOS. We can keep O_RDONLY as a fallback for any other platforms.

Note Nix doesn't seem to have up-to-date support for O_SEARCH / O_EXEC so we may need to fall back to libc or hard-coded constants.

[TheJonny]

thank you for the reply :)
the current implementation (without this PR) relies on the process cwd when opening relative paths before fchdir, so the implementation in this PR using chdir with the same relative path should not worsen anything right now.

[TheJonny]

when using O_PATH / O_SEARCH, should we rename the [w]open_dir functions to open_path or add the flags as argument, to make clear when it is possible to readdir on the returned file descriptor?

[TheJonny]

ok fascinating - macos and freebsd 13 have indeed O_SEARCH, it's just not in the manpages.

so i will have some #[cfg] fun.

[TheJonny]

@ridiculousfish i implemented the alternative in #10442