Tracking Issue for `normalize_lexically`

[ChrisDenton]

View all comments

Feature gate: #![feature(normalize_lexically)]

This is a tracking issue for Path::normalize_lexically that is used to normalize a path, including .. parent references, without touching the filesystem.

Public API

// std::path

impl Path {
    pub fn normalize_lexically(&self) -> Result<PathBuf, NormalizeError> {
}

Steps / History

• API Change Proposal
• Implementation: Implement normalize_lexically #134696
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Should PathBuf have a method that normalizes in-place? Normalizing a path just removes components.
• Should this disallow resolving to the empty path or the single . path.
• Should this only allow paths without a root or prefix? It may be surprising that base_path.join(user_path.normalize_lexically()?) can still escape the base path.

The last two can be summarised as: should this strictly require paths to be sub-paths?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[ChrisDenton]

The basic implementation is now implemented in nightly if people would like to experiment.

[clarfonthey]

Should this take &mut self and normalize in-place? Normalizing a path just removes components.

This could be done for PathBuf, but &mut Path cannot actually delete anything, since the resulting path has to be the same length. Maybe it could be done in a way similar to partition_dedup where all the components are moved to the end, but that would be confusing and a PathBuf-based method sounds much better API-wise.

[ChrisDenton]

We could have a function both on Path and PathBuf. The only issue would be choosing names to distinguish them. normalize_lexically is already a bit of a mouthful (somewhat intentionally since it shouldn't be what people reach for by default).

[clarfonthey]

How would you do a function on Path that removes components of the path in-place, given what I mentioned?

[ChrisDenton]

No, I meant have a function on Path that returns a PathBuf and a separate function on PathBuf that does in-place normalisation.

[clarfonthey]

Ah, yeah, that makes sense. I was mostly commenting on the note at the end that taking &mut self would only work on PathBuf, meaning that it would be worthwhile to have both.

[ChrisDenton]

I've updated it to suggest adding a method to PathBuf instead. If anyone wants to implement that then feel free, I probably won't get to it for awhile.

[MikkelPaulson]

I'm not sure that it makes sense for this operation to be fallible. Given an input of "abc/../../def", an output of "../def" seems perfectly reasonable. Even /../etc, which seems like it should be an error, is silently resolved to /etc on Linux.

There is absolutely a strong use case for checking if a path escapes the pwd, but normalize_lexically:

a) isn't a one-stop shop for this because it will happily represent absolute paths; and
b) isn't an efficient solution to that problem because it allocates.

With that in mind, I suggest always returning a PathBuf rather than Result<PathBuf, _>.

On that note, does it make sense to return a Cow<'_, Path> to avoid allocating when no change is made? This is already done for eg. with_trailing_sep().

[clarfonthey]

I definitely agree that it would be reasonable for this API to return Cow<'_, Path>, alongside my previous recommendation to add a version that just applies to PathBuf in-place.

Also in agreement that it would be reasonable for the final result to contain relative paths, assuming that any .. are at the beginning of the path. I mean, after all, abc is a relative path.