Tracking Issue for Path::file_prefix

[mbhall88]

Feature gate: #![feature(path_file_prefix)]

This is a tracking issue for an implementation of the method std::path::Path::file_prefix. It is effectively a "left" variant of the existing file_stem method.

Public API

use std::path::Path;

let path = Path::new("foo.tar.gz");
assert_eq!(path.file_prefix(), Some("foo"));

Steps / History

• Implementation: add file_prefix method to std::path #85166
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[schwern]

How about a corresponding file_suffix? That completes the set. file_stem/extension and file_prefix/file_suffix.

    pub fn file_suffix(&self) -> Option<&OsStr> {
        self.file_name().map(split_file_at_dot).and_then(|(_before, after)| Some(after))
    }

use std::path::Path;

let path = Path::new("foo.tar.gz");
assert_eq!(path.file_prefix(), Some("foo"));
assert_eq!(path.file_suffix(), Some("tar.gz"));

assert_eq!(path.file_stem(), Some("foo.tar"));
assert_eq!(path.extension(), Some("gz"));

[mbhall88]

@schwern that is indeed a nice idea. I guess it would be best to get the go ahead from someone in the libs team?

I don't know how these tracking issues work. The PR for this feature was merged a while ago, but I have no idea if I'm supposed to do something with this issue? @dtolnay as you were the reviewer/merger of that PR are you able to answer this?

[cyqsimon]

Any progress on this? It's a very useful API when working with files like tarballs.

[mbhall88]

@cyqsimon it is currently on nightly I believe. Not sure how long it takes to get onto stable though.

As for @schwern's suggestion, I guess that would have to be raised as a separate PR/issue and approved by someone on the libs team.

[hustcer]

How about a corresponding file_suffix? That completes the set. file_stem/extension and file_prefix/file_suffix.

Good point !

[yescallop]

One of my concerns is that a file_prefix or file_suffix method that simply slices the path wouldn't be very much useful, because it is common that users insert dots in the meaningful part of file names, such as File Version 3.5.4 (Copy).tar.gz (from Jacob Lifshay on Zulip Chat). The current file_stem and extension methods exist mainly because of File Associations on Windows and common practice on Linux, while it is relatively rare that one would need the exact part of file name before or after the first dot.

I'd suggest adding this to the unresolved questions, if possible.

[lmapii]

While it might be impossible to have a 100% correct implementation in my opinion it would already be helpful to simply have all rust crates behave in a known manner. E.g., there are now hundreds of rust crates out there dealing with files, e.g., matching filenames, all behaving a little different. It is impossible to know how a rust crate that you're including will behave.

Even having a method that might change over time and for which it is documented how it behaves in certain corner cases would be very, very useful. Compare it to the pathlib in python: It is not perfect but it is a beautiful piece of software to use.

[EvanCarroll]

while it is relatively rare that one would need the exact part of file name before or after the first dot.

It's not actually relatively rare. We went over this in voice chat. I gave you multiple reasons why someone would want to do this. In practice,

• .tar.gz
• .spec.ts
• .openapi.yaml
• .conf.d (for an example in a directory)

It's very popular with javascript (where there is no magic byte and everything is js or ts) .d.ts, .conf.json, .conf.js, .rc.json, rc.js, .esm.js, .cjs.js. But also with translations .ru.md etc. Are all common practices that we have to contend with right now many of these in the same project.

---

The current suggestion to get the functionality is,

.file_name().and_then(OsStr::to_str).map_or(false, |name| name.ends_with(".tar.gz"))

Which I think is a bit convoluted. I am down for doing this other ways, but I don't think something like this should is "rare" as far as path manipulation goes, or that it should require converting to-and-from str. I think the simple-most question here is

• Do we want file_suffix to return the . that file_prefix leaves? My own preference, I think file = file_prefix + file_suffix if we go down that route.

We could potentially find better ways to do all of this though. Like simply returning an iterator for file_parts where given foo.bar.tar.gz could be (list monster in graphic below),

• .next().collect::<OsStr>(), what I think of as extension (.bar.tar.gz), and I'm patching to be called .file_suffix() (List Monster tail)
• .last(), what we currently call .extension() (List Monster last)
• .first() what we currently call .file_prefix() (List Monster head)
• file_stem would be all but the last element (not sure if there is a nice way to do that in Rust).. (List Monster init)

The bottom line here is that when it comes to the file name, people will logically think of splitting on . and want names for all possible sets/strings of that list, (from the List Monster in Learn You a Haskell)

Something about that API of returning an Iterator just seems simpler than arguing about whether an "extension" in foo.tar.gz is .tar.gz, tar.gz, .gz or gz.

[yescallop]

There might've been some misunderstandings here. Let's take this file name File Version 3.5.4 (Copy).tar.gz (from Jacob Lifshay) as an example.
In this case, .file_prefix() returns File Version 3 while .file_suffix() returns .5.4 (Copy).tar.gz. If you need to determine if this file name ends with .tar.gz or not, you still need to do stuffs like

.and_then(OsStr::to_str).map_or(false, |name| name.ends_with(".tar.gz"))

IMO this is not optimal. Maybe we could add methods ends_with and strip_suffix on OsStr if this is sufficient for most use cases. But things are getting too complicated in here.

[EvanCarroll]

I can see the utility in better processing for File Version 3.5.4 (Copy).tar.gz. We could define a filename as

filename            = ( file_stem, extension? );
file_stem           = ( dotfile | non_dots );
dotfile             = ( "." + non_dots );
extension           = extension_segment+;
extension_segment   = ("." , valid_extension );
non_dots            = [^.]+?;
valid_extension     = [^\s.]+;

I believe the above would make such that

File Version 3.5.4 (Copy).tar.gz

Gets parsed as

file_stem = "File Version 3.5.4 (Copy)"
extension = ".tar.gz"

But it's probably still not sufficient because if the filename was instead File Version 3.5.4.tar.gz there would literally be nothing you could do if you desired file_name to be File Version 3.5.4. And I think that's fine. That's why I advocate returning an iterator for extension in the above comment, which is what Python does too. That makes processing easier.

---

IMO this is not optimal. Maybe we could add methods ends_with and strip_suffix on OsStr if this is sufficient for most use cases. But things are getting too complicated in here.

I agree with the OsStr suggestion. It doesn't make sense anyway not to have strip_suffix, strip_prefix, starts_with and ends_with on OsStr. But I still think having good pathing functionality in the library should be a goal, rather than to throw up our hands and say it's "too complex" or to pretend like it's rare to want to know an extension on a file. (Discussion topic on this suggestion opened https://internals.rust-lang.org/t/feature-request-starts-with-and-ends-with-on-osstr/16652)

[mbhall88]

We could potentially find better ways to do all of this though. Like simply returning an iterator for file_parts where given foo.bar.tar.gz

I think this is probably the "correct" way to approach this. With such an iterator method we can easily implement any/all flavours of splitting up file names.

In borrowing from python's pathlib (which is very ergonomic), it may be as simple as implementing something akin to suffixes. Because with the method this issue tracks (file_prefix), and a new method suffixes, you have all parts.

Using the running example of the corner case file name

use std::path::Path;

let path = Path::new("path/to/File Version 3.5.4 (Copy).tar.gz");
let mut exts = path.suffixes()

assert_eq!(path.file_prefix(), Some("File Version 3"));
assert_eq!(exts.next(), Some(".5"));
assert_eq!(exts.next(), Some(".4 (Copy)"));
assert_eq!(exts.next(), Some(".tar"));
assert_eq!(exts.next(), Some(".gz"));
assert_eq!(exts.next(), None);

Although, I can also understand the argument that the following is more "complete"

use std::path::Path;

let path = Path::new("path/to/File Version 3.5.4 (Copy).tar.gz");
let mut parts = path.file_parts()

assert_eq!(parts.next(), Some("File Version 3"));
assert_eq!(parts.next(), Some(".5"));
assert_eq!(parts.next(), Some(".4 (Copy)"));
assert_eq!(parts.next(), Some(".tar"));
assert_eq!(parts.next(), Some(".gz"));
assert_eq!(parts.next(), None);