Path::join should concat paths even if the second path is absolute

[carllerche]

Given:

let a = Path::new("/foo");
let b = Path::new("/bar");

I would expect that a.join(&b) would return /foo/bar, however it returns /bar. Given my experience w/ path joining in Ruby and Go, I would expect that join concats two paths and does some normalization to remove double slashes, etc...

There is also a need for a fn that expands a path relative to a given location, which is what Path::join does today. In Ruby, it is named expand_path.

[aturon]

cc @kballard

Some other libraries (Haskell, SML basis) only provide something akin to our current join. Not sure about Boost.

I don't see a great Windows story here, either: Path::new("c:\\temp").join(Path::new("c:\\windows")). We'd need to figure out a coherent specification.

Honestly, it seems a bit weird to me to take something that's syntactically an absolute path and want to treat it as a relative path. In my experience using path, the current join function is what I want. It'd be helpful to know a bit more why this case is coming up for you.

[lilyball]

I agree with @aturon. The only sensible operation when joining an absolute path onto some other path is to get the absolute path back. Doing anything else is just weird, and only makes sense if you actually think of paths as strings, where "join" is "append, then normalize". I do not understand why Go's path.Join behaves in this way, although they are actually taking strings as arguments.

FWIW Ruby actually matches our join. At least, if you use Pathname it does: Pathname("a").join(Pathname("/b")) == Pathname("/b"). File.join() matches Go, but it also operates on strings, and AFAIK Pathname is considered the better way to manipulate paths. Note that File.join() is actually documented as "Returns a new string formed by joining the strings using File::SEPARATOR", and so is not actually even attempting to represent paths, merely do a trivial bit of string manipulation.

[retep998]

In C++ using std::path when I join the two paths C:\foo and C:\bar I get C:\foo\C:\bar.

[lilyball]

@retep998 C++ doesn't have a std::path.

[retep998]

@kballard I was using the <filesystem> library which is a TS going through the final committee vote and MSVC has already implemented it.

[lilyball]

@retep998 Sounds like a really crappy path definition then. I guess that's what you get with design-by-committee.

According to MSDN, basic_path::operator/ is defined as concatenating the strings that the paths wrap. That's a really braindead approach. If it's just going to do string operations, why would I ever use std::path instead of just using std::strings directly?

[retep998]

Because std::path is the only way to work with unicode paths in a cross-platform manner (using std::string is locale-specific), all the filesystem APIs work with std::path instead of std::string, and it has methods to extract various components of the path.
path::operator/ does a bit more than just concatenation according to cppreference.

[retep998]

The C++ committee has recently been dealing with this problem.
http://isocpp.org/files/papers/n4211.html issue 64

[Boddlnagg]

C# (or rather the .NET standard library) also matches the current behavior:
"If path2 contains an absolute path, this method returns path2." (MSDN)

[l0kod]

The join() function is often misused and leads to security vulnerabilities.

Moreover, there is now a documentation indirection pointing to PathBuf::push() :(

The Path reform should get ride of this dangerous behavior. The join() could return something like Result<PathBuf, PathError> to exclude an absolute path as argument.
There is also a name inconsistency between the Path::join() and the PathBuf::push().

cc #20034

[aturon]

The join() function is often misused and leads to security vulnerabilities.

Note that this talks about not just absolute paths, but also relative paths that begin with .. for example. I don't think that simply ruling out joining absolute paths (which certainly has its uses) is enough to solve this problem, and I'm not sure that std should be legislating policy at this level.

Moreover, there is now a documentation indirection pointing to PathBuf::push()

@steveklabnik What's our standing policy here? Do we prefer to have multiple copies of very similar docs?

There is also a name inconsistency between the Path::join() and the PathBuf::push().

This bothered me with the old path API as well, but I wasn't able to come up with a better solution. Do you have any suggestions?

cc @alexcrichton

[l0kod]

The PR #5023 added an unsafe_join() and an is_restricted() functions who seem to have been lost…

I like splice() to express that the path argument is concatenated and do not replace self.
I think that Path and PathBuf should have the same function name as they have the same meaning.

Of course, this apply to join_many().

Name ideas:

• splice()
• push()
• concat()
• chain()
• append()
• nest()