(moderated summary by the WG)
.., .., // not being auto- handled- windows gotchas, like long file paths (which require extended-length paths aka "verbatim paths" as they're called in std)
- absolute paths on Windows (UNC prefices)
- UTF-8 filenames on MacOS (the filesystem normalizes UTF-8 strings)
- atomic file writes
- Path.join: A method that both concatenates a path or completely replaces the existing one based on the input ... when did one ever have that use-case?
- "Simple" API that comes at the cost of performance for rapid prototyping / throwaway "scripts", see also https://github.com/rust-lang-nursery/cli-wg/issues/26
- Priority should be on working out how the normal rust stuff should behave before wrapping it up in the high level, python-
pathlib-like API.
format! a path for a command line argument or mutating a path can cause problems with the non-UTF8 nature of OsStr
In the first meeting, we talked a bit about the pain points of dealing with files and path in a cross-platform manner.
One idea is to create or improve crates that provide higher-level abstractions than std in this area.
(moderated summary by the WG)
..,..,//not being auto- handled\\?\where needed on Windows rust-lang/rust#32689pathlib-like API.format!a path for a command line argument or mutating a path can cause problems with the non-UTF8 nature ofOsStr@killercup's original post
In the first meeting, we talked a bit about the pain points of dealing with files and path in a cross-platform manner.
One idea is to create or improve crates that provide higher-level abstractions than
stdin this area.