Skip to content

std::os: Add get_path_env() #11324

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

klutzy
Copy link
Contributor

@klutzy klutzy commented Jan 5, 2014

This primary motivation is that there was no easy way to get list of
paths from getenv("PATH"), because it requires to split string with
os-depdent separator.
rustc also did same work for RUST_PATH, so this patch moves the
portion into std::os for public use.

This primary motivation is that there was no easy way to get list of
paths from `getenv("PATH")`, because it requires to split string with
os-depdent separator.
rustc also did same work for `RUST_PATH`, so this patch moves the
portion into std::os for public use.
@alexcrichton
Copy link
Member

I'm a little unsure of how serious we want to get with this, but I know that with libuv they attempt to parse the path on windows as well, and apparently it's not as easy as just splitting on semicolons (right now their path parsing causes an infinite loop).

If we do take this route, I fear that we'll eventually get a bug reporting saying that we're not parsing the windows paths correctly.

One route to take would be to only define the separator in libstd (which I think is done in std::path), and another route would be true path parsing for windows (I'm unsure if unix has the same ability). What do you think?

@klutzy
Copy link
Contributor Author

klutzy commented Jan 6, 2014

Ugh windows! I presumed simple split works because gcc does for LIBRARY_PATH parsing, but it seems that PATH is more complicated.
posix says PATH is colon-separated so I think it's safe for unix.
On Windows, it seems that there is no concrete documentation of its syntax. libuv needs full emulation because they have to do it, but we don't. I started to think this patch doesn't provide good use cases to require such effort, so I'm closing this unless good reason is found. :-)

On the other hand, we may have to clarify what RUST_PATH syntax is. It is currently different to (and better than) PATH syntax on Windows.

@klutzy klutzy closed this Jan 6, 2014
flip1995 pushed a commit to flip1995/rust that referenced this pull request May 2, 2024
fix suggestion error for [`manual_is_ascii_check`] with missing type

fixes: rust-lang#11324
fixes: rust-lang#11776

changelog: improve [`manual_is_ascii_check`] to suggest labeling type in closure, fix FP with type generics, and improve linting on ref expressions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants