I got this error on Windows:

error[E0277]: the trait bound `*mut std::os::raw::c_void: std::marker::Send` is not satisfied in `plugin::Plugin`
  --> src\monitor.rs:80:48
   |
80 | pub fn monitor_signal(plugins: Vec<Plugin>) -> impl Future<Item = (), Error = io::Error> + Send {
   |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `*mut std::os::raw::c_void` cannot be sent between threads safely
   |
   = help: within `plugin::Plugin`, the trait `std::marker::Send` is not implemented for `*mut std::os::raw::c_void`
   = note: required because it appears within the type `subprocess::win32::Handle`
   = note: required because it appears within the type `subprocess::popen::os::ExtChildState`
   = note: required because it appears within the type `subprocess::popen::ChildState`
   = note: required because it appears within the type `subprocess::Popen`
   = note: required because it appears within the type `plugin::Plugin`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::ptr::Unique<plugin::Plugin>`
   = note: required because it appears within the type `alloc::raw_vec::RawVec<plugin::Plugin>`
   = note: required because it appears within the type `std::vec::Vec<plugin::Plugin>`

I have a struct Plugin with a member of type subprocess::Popen.

Can Popen be Send?

I'm trying to create something that works kind of like a shell using subprocess. A user enters a command in a webview and this executes the command in a subprocess inside a new thread. I'm trying to communicate with them using channels from the main thread and send messages from there to the subprocesses. I've managed to make stdout/err work like this but I'm having trouble with stdin.

I've tried a lot of things, here's my current attempt:

let mut p = Exec::cmd(command)
    .args(&args)
    .cwd(current_dir)
    .stdin(Redirection::Pipe)
    .stdout(Redirection::Pipe)
    .stderr(Redirection::Pipe)
    .popen()?;

let mut stdin = vec![];

while p.poll().is_none() {
    // trying to write stdin (this is not working)
    p.stdin
        .as_ref()
        .unwrap()
        .write_all(&stdin)
        .expect("Failed to write stdin");

    let mut reader = BufReader::new(p.stdout.as_ref().unwrap());
    let mut chunk = [0u8; 64];
    loop {
        let len = reader.read(&mut chunk)?;
        if len == 0 {
            break;
        }
        let chunk = &chunk[..len];

        // send stdout
        let event_result = tauri::event::emit(
            webview,
            "event",
            Some(Payload {
                id: id.clone(),
                chunk,
            }),
        );
        if let Err(err) = event_result {
            println!("Failed to send chunk: {}", err);
        } else {
            println!("Sent chunk");
        };
    }

    // receive stdin message
    let received = receiver.recv();
    if let Ok(message) = received {
        if message == "Exit" {
            println!("Exiting");
            break;
        }

        println!("Message received: {}", message);
        stdin = message.as_bytes().to_owned();
    } else {
        println!("No message or error");
    }
}

Please let me know if it's unclear what I'm trying to do. Any help would be appreciated, and thanks for your time!

I'm noticing that subprocess is doing a bit of extra work processing the arguments, and while helpful, it seems like it's not allowing me to encode certain types of calls.

In Windows, for example, there is a difference between:

echo foo

and

echo "foo"

The latter of these doesn't seem be expressible in subprocess. If I add an argument that is "foo", subprocess will create a second set of quotations around the first, and then escape the first. This isn't what you want. If the quotes are at the outside and not inside, I don't believe you want to escape them.

Compiling on windows gives a bunch of

 expected enum `libc::c_void`, found enum `winapi::ctypes::c_void`

I've tried with:

• stable-x86_64-pc-windows-gnu (1.31)
• stable-x86_64-pc-windows-msvc (1.30)
• nightly-x86_64-pc-windows-msvc (1.32)

I believe under the current implementation there is no way to call communicate multiple times to a subprocess that terminates on EOF. It would be nice if there was some sort of mechanism by which I could write to a subprocess without sending eof, such that I could read its response and send more based on the response. I apologize if this is already possible, or if my lack of understanding of the implementation is preventing me from seeing if this is impossible.

help: within `subprocess::popen::Popen`, the trait `std::marker::Sync` is not implemented for `*mut bitflags::core::ffi::c_void`
   = note: required because it appears within the type `subprocess::win32::Handle`
   = note: required because it appears within the type `subprocess::popen::os::ExtChildState`
   = note: required because it appears within the type `subprocess::popen::ChildState`
   = note: required because it appears within the type `subprocess::popen::Popen`

From looking at the code in win32.rs there is:

unsafe impl Send for Handle {}

My guess is that this should be solved by adding:

unsafe impl Sync for Handle {}

hey. very nice crate.

im having here a very interesting situation

i have this code; just trying to run a command that is not found on my system using the Exec::shell and get its output and err into 2 variables:

extern crate subprocess;

use subprocess::Exec;
use subprocess::Redirection;

fn main() {
    let out_and_err = Exec::shell("not_found")
        .stdout(Redirection::Pipe)
        .stderr(Redirection::Merge)
        .capture().unwrap();

    let out = out_and_err.stdout_str(); 
    // here out is the error message from shell: 
    // "sh: line 1: not_found: command not found\n"
    println!("{:?}", out);


    
    let err = out_and_err.stderr_str();
    // println!("{:?}", out);
    println!("{:?}", err); // <---- here the error is empty string ""
}

when i run it i do get:

❱  cargo run --example sub
    Blocking waiting for file lock on build directory
   Compiling rust_core v0.0.1 (~/Alexzander__/programming/rust/core)
    Finished dev [unoptimized + debuginfo] target(s) in 1.10s
     Running `target/debug/examples/sub`

"sh: line 1: not_found: command not found\n"
""

my questions are:

• is this the expected behavior when the shell its returning command not found error?
• shouldnt let err = out_and_err.stderr_str(); contain the message sh: line 1: not_found: command not found ?

because when im running not_found in my shell its exiting with code 127:

❱  not_found
zsh: command not found: not_found

鉶(tmux)
 [~/Alexzander__/programming/rust/core]
 git:(main[-US?--UT])
✘ exit:(code[127])           <--------- here
❱

First an idea to improve the example which might relevant for users of this crate that take the example from examples/sample.rs. Shell builtin commands on Windows, like e.g., dir, need to always be run through subprocess::Exec::shell. I used the following code to get the example working on Windows (if you like I'll be happy to open a Pull Request):

extern crate subprocess;

use std::io::{BufRead, BufReader};
use subprocess::Exec;

fn main() {
    #[cfg(not(target_family = "windows"))]
    let x = Exec::cmd("ls").stream_stdout().unwrap();
    #[cfg(target_family = "windows")]
    // on Windows shell builtins like dir need to be run through shell not cmd
    let x = Exec::shell("dir").stream_stdout().unwrap();

    let br = BufReader::new(x);
    for (i, line) in br.lines().enumerate() {
        println!("{}: {}", i, line.unwrap());
    }
}

Furthermore I think there is bug on Windows. Passing a command that is built on more then one word (meaning something surrounded by whitespace), does not work if it passed to subprocess::Exec::cmd. Simple example:

fn main() {
    let x = Exec::shell("cargo").stream_stdout().unwrap();              // works
    let x = Exec::cmd("cargo").stream_stdout().unwrap();                // works
    let x = Exec::shell("cargo --version").stream_stdout().unwrap();    // works
    let x = Exec::cmd("cargo --version").stream_stdout().unwrap();      // does NOT work

    let br = BufReader::new(x);
    for (i, line) in br.lines().enumerate() {
        println!("{}: {}", i, line.unwrap());
    }
}

The error message for the non working example is:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Os { code: 2, kind: NotFound, message: "..." })', src\main.rs:7:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

For the reasons mentioned in the README.md I think it would be good if subprocess::Exec::cmd works well with that type of input on Windows.

Hey, first thanks for a great project, its exactly what I needed.

So I'm looking to execute processes which have no stdin, but I need to capture:

• stdout
• stderr
• exit_code
• and time out a process

I've tried a whole bunch of things. The closest I've gotten is to use the Popen and use the communicate_bytes to get the first 3 of the bullets above, but it blocks and so the wait_timeout doesn't get called.

I looked through other issues, but may have missed it. Any ideas on how to accomplish this?

//This should timeout after 50ms, but blocks on `communicate_bytes` so the `wait_timeout` never can check
#[test]
fn test_sleep_with_timeout_blocks() {
    
    let timeout = Duration::from_millis(50);
    let args = &vec!("sh", "-c", "sleep 5");

    let mut p = Popen::create(
        args, 
        PopenConfig {
            stdout: Redirection::Pipe,
            stderr: Redirection::Pipe,
            ..Default::default()
        }).unwrap();

    // This blocks, so the wait_timeout cant get hit
    // I need the stdout and stderr
    let (maybe_out, maybe_err) = p.communicate_bytes(None).unwrap();
    
    let status = p.wait_timeout(timeout).unwrap();
}

I found myself wanting to use value given by Capture, and found that the struct is sort of private... it's not visible from outside the crate. Is it an oversight?

//it will popup a black console windows in windows #![windows_subsystem = "windows"] extern crate subprocess;

use subprocess::{Exec,Redirection}; use std::io::{BufReader, BufRead}; use std::io::prelude::*; use std::fs::File;

fn main() { let out = Exec::cmd("dir") .stdout(Redirection::Pipe) .capture().unwrap() .stdout_str(); println!("{}",out); let mut file = File::create("out.txt").unwrap(); file.write_all(&out.into_bytes()).unwrap(); }

I have a shell app. Generally, I would open it in a shell, then I input a command "ucci" to it, then it feedbacks some lines of strings. And I would still interact it with other commands until I input "quit", then it would quit.

I wrote code like this:

use subprocess::{Popen, PopenConfig, Redirection};

fn main() -> io::Result<()> {
    let cmd = "./myShellApp.exe";

    // test crate
    let mut p = Popen::create(
        &[cmd],
        PopenConfig {
            stdin: Redirection::Pipe,
            stdout: Redirection::Pipe,
            ..Default::default()
        },
    )
    .expect("open app failed");

    let (out, err) = p.communicate(Some("ucci\n"))?;
    match out {
        Some(s) => println!("{}", s),
        None => todo!(),
    }
    match err{
        Some(e) => println!("{}", e),
        None => todo!(),
    }

But the code just stuck at let (out, err) = p.communicate(Some("ucci\n"))?;. It seems that it would not quit until the sub process in terminated. How should I fix it?

This test is flaky under the following interleaving:

• exec_to_string() grabs MUTATE_ENV.
• env_inherit_set() calls temp_env_var() which calls env::set_var().
• exec_to_string() executes some asserts, one of which fails because the other test messed with the environment in a way exec_to_string() did not expect.
• exec_to_string() panics and poisons MUTATE_ENV.
• env_inherit_set() grabs the lock and panics because it's poisoned.

Taking the lock before setenv fixes this.

Today subprocess gives you a way on unix to put the child in a new process group but, I think, if you terminate or kill it you will only signal the direct child. It would be nice to also expose a safe interface to killpg.

(It's not a big deal as you can do the equivalent through libc or nix but it might be nice.)

Adds the ability to set the process creation flags for Windows process via param in the PopenConfig struct. This is a workaround for #40, so you can, for example, pass flag 0x08000000, which hides the CMD on Windows, or any other flag you want.