Specifying an env in run::ProcessOptions breaks finish_with_output

[catamorphism]

use std::{io, os, run, str};

fn main() {

   let cwd = os::getcwd();
   let mut prog = run::Process::new("echo",
                                    [~"eggplants"],
                                    run::ProcessOptions { env: None,
                                                         dir: Some(&cwd),
                                                         in_fd: None,
                                                         out_fd: None,
                                                         err_fd: None
                                                        });
    let rslt = prog.finish_with_output();
    io::println(fmt!("status = %?; output = %s", rslt.status, str::from_bytes(rslt.output))); 
    assert_eq!(str::from_bytes(rslt.output), ~"eggplants\n");


    let mut prog = run::Process::new("echo",
                                     [~"$EGGPLANTS"],
                                     run::ProcessOptions { env: Some(&[(~"EGGPLANTS",
                                                                        ~"17")]),
                                                          dir: Some(&cwd),
                                                          in_fd: None,
                                                          out_fd: None,
                                                          err_fd: None
                                                         });
    let rslt = prog.finish_with_output();
    io::println(fmt!("status = %?; output = %s", rslt.status, str::from_bytes(rslt.output))); 
    assert_eq!(str::from_bytes(rslt.output), ~"17");
}

The second assertion fails. Also, the "echo" process fails with exit code 1. Something about putting a Some(...) in the env field is breaking process spawning.

This is on Mac OS X; I don't know about other platforms.

[catamorphism]

This is using revision 330378d , btw.

[catamorphism]

Maybe related to #8498. I'll test this again after #8518 lands.

[alexcrichton]

Closing, this has been fixed in the interim, and I highly suspect that fixes to codegen have caused this to be un-broken.

Closing as I believe the test case from #9259 is sufficient