You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AZMCode opened this issue
Feb 2, 2022
· 3 comments
· Fixed by #93635
Labels
A-docsArea: documentation for any part of the project, including the compiler, standard library, and toolsC-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.
As of now, the stable and nightly documentation on std::env::current_dir only states
Returns the current working directory as a PathBuf.
And proceeds to note a couple of errors the function may fail with.
This does not mention the fact that (as far as I am aware, testing on Linux) the path is also canonicalized, having resolved all symlinks in any segment of the path. I'd imagine not documenting this behavior could lead to confusion and/or bugs, if it already hasn't.
I tried this code within a symlink folder /example/symlink/here pointing to /symlink/target/here:
For UNIX Rust just calls getcwd() and that behavior is documented in the POSIX spec, so it will be the same on all conforming implementations. We should document which platform-specific function we call here just like we do with other filesystem functions (e.g. here).
rustbot
added
A-docs
Area: documentation for any part of the project, including the compiler, standard library, and tools
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
labels
Feb 3, 2022
A-docsArea: documentation for any part of the project, including the compiler, standard library, and toolsC-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.
As of now, the stable and nightly documentation on
std::env::current_dir
only statesAnd proceeds to note a couple of errors the function may fail with.
This does not mention the fact that (as far as I am aware, testing on Linux) the path is also canonicalized, having resolved all symlinks in any segment of the path. I'd imagine not documenting this behavior could lead to confusion and/or bugs, if it already hasn't.
I tried this code within a symlink folder
/example/symlink/here
pointing to/symlink/target/here
:I expected to see get the output:
"/example/symlink/here"
Instead, this was output:
"/symlink/target/here"
Currently using the nightly compiler.
For obvious reasons, there's no backtrace.
Update: Read a bit through the code and realized this behavior might be libc-dependent
ldd --version
on my system returnsldd (GNU libc) 2.33
The text was updated successfully, but these errors were encountered: