Conversation
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.
|
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 |
|
Ugh windows! I presumed simple split works because gcc does for On the other hand, we may have to clarify what |
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.
This primary motivation is that there was no easy way to get list of
paths from
getenv("PATH"), because it requires to split string withos-depdent separator.
rustc also did same work for
RUST_PATH, so this patch moves theportion into std::os for public use.