What is the behavior of `std::env::split_paths` when given an empty string?

[lopopolo]

Location

https://doc.rust-lang.org/nightly/std/env/fn.split_paths.html

Summary

The iterator returned by std::env::split_paths yields a single empty empty string when given a "" or OsStr::new("") argument. Is this by design or a bug?

I found it unexpected that an empty path string yielded any paths at all and was curious if this is a quirk of the implementation using slice::Split on the internals.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a57d0e83edebdcbe70e5e2a54424ee9f

use std::env::split_paths;

fn main() {
    println!("{:?}", split_paths("").collect::<Vec<_>>());
    println!("{:?}", split_paths(":").collect::<Vec<_>>());
    println!("{:?}", split_paths("::").collect::<Vec<_>>());
}

outputs:

[""]
["", ""]
["", "", ""]

The second and third output make sense to me. In the absence of documented behavior, I'm not sure about the first one.

If this is the expected behavior, can it be added to the documentation?

[lopopolo]

Thinking about this a bit more, the empty input case follows from noting that split_paths yields empty paths. Showing an example with a path string like ":::" would have made this clear for me.

[ChrisDenton]

Personally I think a case could be made that they should all return an empty iterator. An empty path can be unexpected and lead to errors (I've fixed a few of these).

Either way, I'm unsure if the behaviour can be changed at this point so simply documenting it might indeed be the best approach. But ultimately this is a decision for libs-api.

@rustbot label +libs-api +S-waiting-on-team

[Amanieu]

The current behavior is correct, at least base on the way libc does PATH parsing. The empty string is treated as the current directory. You can test this in shell with:

touch foo
chmod +x foo
PATH= foo

[ChrisDenton]

Huh, the behaviour of powershell on Windows is different.

Z:\hello> $env:Path += ';;'
Z:\hello> hello
hello: The term 'hello' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Suggestion [3,General]: The command hello was not found, but does exist in the current location. PowerShell does not load commands from the current location by default. If you trust this command, instead type: ".\hello". See "get-help about_Command_Precedence" for more details.
Z:\hello> $env:PATH += '.'
Z:\hello> hello
Hello!

It's unfortunately not uncommon for PATH to have a trailing ; accidentally added (or not removed) by some tool or other. And for security reasons, it's important that the current directory not accidentally appear in PATH (although you can of course force it).

[Amanieu]

We could just make the behavior platform-dependent and document it as such. The general understanding being that this work the same way OS path lookup does.