sharkdp / argmax Goto Github PK

Commands inherit the parent's environment variables by default. Right now we check the size of the environment when you create a Command, but it can be modified in the meantime:

    #[test]
    fn test_env() {
        let mut cmd = Command::new("/bin/echo");

        // Add as many arguments as possible                                                                                                                                                                                                                                    
        while cmd.try_arg("foo").is_ok() {}

        for i in 0..1024 {
            std::env::set_var(format!("VAR{i}"), "VALUE");
        }

        assert!(cmd.status().unwrap().success());
    }

test tests::test_env ... FAILED

failures:

---- tests::test_env stdout ----
thread 'tests::test_env' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 7, kind: ArgumentListTooLong, message: "Argument list too long" }', src/lib.rs:204:30

We can document that std::env::set_var() invalidates the calculations I guess. But we'll still have to think about this to implement try_env() if we want it.

This is the current state (copied from sharkdp/fd#410)

• fix compile errors on all fd-supported platforms
  • i686-pc-windows-mscv
  • i686-unknown-linux-gnu
  • i686-unknown-linux-musl
  • x86_64-apple-darwin
  • x86_64-pc-windows-gnu
  • x86_64-pc-windows-mscv
  • x86_64-unknown-linux-gnu
  • x86_64-unknown-linux-musl
• fix unit test on all platforms
  • i686-pc-windows-mscv
  • i686-unknown-linux-gnu
  • i686-unknown-linux-musl
  • x86_64-apple-darwin
  • x86_64-pc-windows-gnu
  • x86_64-pc-windows-mscv
  • x86_64-unknown-linux-gnu
  • x86_64-unknown-linux-musl
• Make sure that enforced limit is reasonably close* to actual (experimental) limit
  • i686-pc-windows-mscv (679 vs 2045)
  • i686-unknown-linux-gnu (348,906 vs 349,417)
  • i686-unknown-linux-musl (10,295 vs 349,409)
  • x86_64-apple-darwin (20,585 vs 21,096)
  • x86_64-pc-windows-gnu (679 vs 2045)
  • x86_64-pc-windows-mscv (679 vs 2045)
  • x86_64-unknown-linux-gnu (348,329 vs 348,841)
  • x86_64-unknown-linux-musl (10,294 vs 349,408)

*reasonably close: it shouldn't be an order of magnitude smaller than the actual limit.

Continuing the discussion from sharkdp/fd#410 (comment)

The actual argv/envp pointer are counted in units of size_of::<*const c_char>():

But this is wrong if a 32-bit program is launching a 64-bit one on a 64-bit kernel. This leads to this failure: https://github.com/sharkdp/argmax/runs/4231259608?check_suite_focus=true. It can be reproduced locally with

$ rustup target add i686-unknown-linux-gnu
$ cargo test --target=i686-unknown-linux-gnu
...
Trying execution with 260638 args
thread 'can_run_command_with_maximum_number_of_arguments' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 7, kind: ArgumentListTooLong, message: "Argument list too long" }', tests/main.rs:49:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

A conservative fix would be to assume that pointers are at least 8 bytes wide on all platforms. Ideally we'd only do this on 64-bit kernels, but I don't know a good way to detect that from userspace.