musl+gcompat error

[Conaclos]

Hi! I tried to use a rust crate that relies on pico-args using Alpine Linux (Musl-based distrib) and gcompat (glibc compatibility layer). I got the following error:

Message: removal index (is 0) should be < len (is 0)

at the following line: https://github.com/RazrFalcon/pico-args/blob/master/src/lib.rs#L127

It could be nice to add a defensive check and then removing the path only if it is present.

[RazrFalcon]

How is it possible not to have the executable path? Isn't this against the standard?

The first element is traditionally the path of the executable, but it can be set to arbitrary text, and might not even exist.

Damn...

[rjsberry]

I've reproduced this on an M1 Mac:

$ docker run --rm -it --platform linux/amd64 alpine
# apk add gcompat libgcc

std::env::args_os() always returns an empty iterator, even if I pass the program arguments. For reference in this environment clap doesn't panic but of course it also doesn't work.

rust-lang/rust#124126

[rjsberry]

@Conaclos Looks like this will be working in Rust 1.79: rust-lang/rust#124447.

[RazrFalcon]

Nice! Even better then fixing it locally.

[duckinator]

I ran into this problem, but in a different context: I have a project that uses the same codebase for both native and wasm builds. I get this error on the wasm build.

At the moment I'm handling it in my app, but it feels like the wrong place to handle it.

In theory, I think adding a conditional to from_env() like this should fix it:

    pub fn from_env() -> Self {
        let mut args: Vec<_> = std::env::args_os().collect();
        if args.len() > 0 {
            args.remove(0);
        }
        Arguments(args)
    }

Would a PR adding that conditional be accepted, @RazrFalcon? Or should I just stick to the workaround in my project?

(Either way, thank you for making pico-args!)

[RazrFalcon]

like this should fix it

The problem is that I have to know if the first argument an exe path or not and I don't. You logic will not work for the most basic cases like -h. It would just eat the first argument.

The only solution I can think of is adding from_env_no_exe.