I can't use expect() directly to read lines for line processing because I need non-blocking reads. Using non-blocking reads allows more control while waiting for data to be available. For example, I add an animated cursor if the data takes too long to appear.

Here's the current code, roughly. It's loosely based on the expectrl source code using try_read here.

The following code shows a number of useful expectrl features. Specifically, it:

• Catches \r and \n as the command writes lines, allowing them to be rewritten. This is useful because some commands emit just \r to overwrite the previous line in a terminal rather than scrolling.
• Allows lines to be read individually and processed.
• Allows timeouts to be checked.
• Allows other processing in the loop, such as starting an animated cursor or waiting message if the command is taking too long to emit any output.

    use expectrl::{Session, Signal, WaitStatus};
    use std::io::{stdout, Write};
    use std::{process::Command, thread, time::Duration, time::SystemTime};

    fn main() {
      let mut cmd = Command::new("ping");
      cmd.args(&["www.time.org"]);

      let mut session = Session::spawn(cmd).expect("failed to execute process");
      thread::sleep(Duration::from_millis(300)); // Give the process a moment to start.

      let mut buf = vec![0; 512]; // Line buffer.
      let mut b = [0; 1]; // Read buffer.
      let sys_time = SystemTime::now();
      loop {
        match session.try_read(&mut b) {
          Ok(0) => {
            println!("==> EoF");
            break; // EoF
          }
          Ok(_) => {
            buf.push(b[0]);
            if b[0] == 10 || b[0] == 13 {
              stdout().write_all(&buf).unwrap();
              stdout().flush().unwrap();

              // (1) Further process the line as needed. 
              // ...

              buf.clear();
            }
          }
          Err(err) if err.kind() == std::io::ErrorKind::WouldBlock => {}
          Err(err) => {
            println!("err {}", err);
            break;
          }
        }
        // Check for timeout.
        // Start/update animated cursor if there's no output
      }

      match session.wait() {
        Ok(WaitStatus::Exited(pid, status)) => {
          println!("child process {} exited with: {:?}", pid, status);
        }
        // Signaled() is expected if the process is terminated.
        Ok(WaitStatus::Signaled(_, s, _)) => {
          println!("child process terminated with signal: {}", s);
        }
        Err(e) => {
          println!("error waiting for process: {:?}", e);
        }
        s => {
          println!("unhandled WaitStatus: {:?}", s);
        }
      }
    }

This code works because Session provides a try_read() that doesn't block. Currently,expect() already provides many of these features, including timeouts and the Any() method to detect specific line endings. But expect() blocks. With expect() blocking, I would have to multithread cursor animation and synchronize terminal writes. Doable, but it adds complexity that the try_read() approach avoids.

The problem: How to allow interactive typing into the terminal, with the line processing as above? There's interactive()but it can't be used in this context because it blocks.

Possible solutions:

1. Could there be a version of interactive() that emits lines for processing?
2. Could there be a version of interactive() that accepts a passed-in function for line processing or other work? (eg, at (1) above).
3. Could there be a try_interactive() allows interactivity, but checks for data written to stdout without blocking?

Programs that ask for passwords don't repeat them as they're typed. For example,

$ sudo ls
Password:

but doesn't show the characters typed by the user. Here's a program using expectrs to do the same:

use expectrl::Session;
use std::process::Command;

fn main() {
    let mut cmd = Command::new("sudo");
    cmd.arg("ls");
    let mut session = Session::spawn_cmd(cmd).expect("Error while spawning");
    let status = session.interact().expect("Failed to start interact");
    println!("Exit status {:?}", status);
}

But it repeats whatever is typed.

Running `target/debug/expectrl_test`
Password: sdf

In my bash shell, the Password: prompt is actually followed by a key symbol, which seems to be a property of bash, not sudo.The same effect is seen with read -s, which I believe is a bash built-in and might be useful for testing.

hi, we're trying to migrate from rexpect to this crate in https://github.com/anoma/anoma/pull/1095. It was pretty smooth, thank you for this crate! We just hit couple road-blocks - one of them is that the lazy approach in Session::expect is too slow for processes with many lines of output. We get around it by adding this expect_eager variation.

Example, following example will cause 100% CPU usage.

fn main() {
    let shell = "bash";
    let mut sh = expectrl::spawn(shell.to_string()).expect("Error while spawning sh");

    println!("Connecting to {}", shell);

    sh.interact().unwrap();
}

hi again, just a small fix-up to get sync_session to show up in docs. There are bunch of other things with #[cfg(not(feature = "async"))] that get excluded, but because they share the same name in #[cfg(feature = "async")], enabling those doesn't work together :/

Running another spawn() after calling interact() causes the spawn to fail with a Sys(EBADF) error.

If the repro code below is run without the interact() function, it calls spawn() and prints the process info as expected:

Running PtyProcess { master: Master { fd: PtyMaster(7) }, child_pid: Pid(97435), stream: 
Stream { inner: File { fd: 9, path: "/dev/ptmx", read: true, write: true }, reader: BufReader { 
reader: Reader { inner: File { fd: 10, path: "/dev/ptmx", read: true, write: true } }, buffer: 0/8192 
} }, eof_char: 4, intr_char: 3, terminate_approach_delay: 100ms }

However, if the interact() function is called, the subsequent call to spawn() fails:

Cargo.lock	Cargo.toml	src		target
Quiting status Exited(Pid(96414), 0)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Sys(EBADF)', src/main.rs:20:42
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Repro code:

use expectrl::Session;
use ptyprocess::PtyProcess;
use std::{process::Command, thread, time::Duration};

fn main() {
    let cmd = Command::new("ls");
    let mut bash = Session::spawn_cmd(cmd).expect("Error while spawning bash");
    //
    // If these two lines are commented out, the spawn() below starts and the
    // process information is printed.
    //
    // If these two lines are enabled, the interact() succeeds and the exit code
    // 0 is printed, but the spawn() below panics.
    let status = bash.interact().expect("Failed to start interact");
    println!("Quiting status {:?}", status);

    // Now start another.
    thread::sleep(Duration::from_millis(500));   // Delay just in case.

    let cmd = Command::new("ls");
    let process = PtyProcess::spawn(cmd).unwrap();
    println!("Running {:?}", process);
}

Tested on macOs.

expectrl::Session::spawn() accepts a std::process::Command, allowing some options like which directory to run in. Is it compatible with interact()? Or should expectrl::spawn also have a version that accepts a Command?

This code works as expected, printing out the help for git diff, then exiting:

let mut cmd = std::process::Command::new("git");
cmd.args(["diff"]);
cmd.current_dir("/tmp");
let mut session = expectrl::Session::spawn(cmd).expect("Can't spawn a session");
let mut opts = expectrl::interact::InteractOptions::terminal().unwrap();
let res = opts.interact(&mut session).unwrap();

But when a Command is used with the code in this comment of issue 13, Some unexpected behavior occurs.

Specifically, (1) replacing

let mut session = expectrl::spawn("./terminal_example.py").expect("Can't spawn a session");

with

let mut cmd = std::process::Command::new("git");
let mut session = expectrl::Session::spawn(cmd).expect("Can't spawn a session");

causes the output to stop partway through printing the git help.

(2) Replacing the spawn line with

let mut cmd = std::process::Command::new("git");
cmd.args(["diff"]);
let mut session = expectrl::Session::spawn(cmd).expect("Can't spawn a session");

works as expected.

(3) Replacing the spawn line with

let mut cmd = std::process::Command::new("git");
cmd.args(["diff"]);
cmd.current_dir("/tmp");
let mut session = expectrl::Session::spawn(cmd).expect("Can't spawn a session");

also causes the output to stop partway through printing the git help.

There could be several issues here:

1. It's notable that the simple example above works as expected, but the demo code doesn't. Is there something about using on_output or on_idle that causes the problem?
2. How do we use a spawn that accepts a Command and works with interact()?
3. Which spawn is the right one to use with interact()? It seems confusing to have multiple functions with similar names in different namespaces, eg Session::spawn() vs expectrl::spawn().

To reproduce: run interact example execute this in the spawned shell: python -c "print('\n'*10000000)" (or more if it doesn't error ;))

Error: thread 'main' panicked at 'Failed to start interact: IO(Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" })', examples/interact.rs:23:10

Full backtrace: err.txt

Relevant setup info: Linux 6.0.1, alacritty terminal

This doesn't happen in other programs that do similar things (poetry, qmk). There everything works as expected

PS: It also can happen in not-so-extreme scenarios, but that's a reliable way to reproduce this

Thanks for the wonderful library. I want to create my custom ReplSession, but ReplSession::new function is private. So how can I create ReplSession from some sessions outside of this library?

I want to run program following:

let session = expectrl::repl::ReplSession::new(
    expectrl::spawn("mycommand").unwrap(),
    "EXPECT_PROMPT".to_string(),
    None, false);
let recv = session.execute("send");

As things are now, Session::spawn() expects std::process::Command on Unix-like platforms and conpty::ProcAttr on Windows (the documentation only mentions the former). The API doesn’t expose the command type in use, this type is private. As a result, my code has to depend on conpty even though it doesn’t actually use it.

The way I see it, expectrl could at least expose the command type publicly. But ideally it would really take the standard std::process::Command structure on all platforms and convert to conpty::ProcAttr itself.

If you take a look what we print here.

cargo run --example bash

You will find a list of sequences which aren't expected at all ...

https://github.com/zhiburt/expectrl/blob/6b53972e2ffd5102bbc632d3025db65b6e73c663/examples/bash.rs#L17

Today when using interact the exit code is lost because is_alive will swallow it. It would be nice if the session could hold on to the status() so that it can be called again later to retrieve the first observed status.

Consider the following very simple use of expectrl:

use expectrl::{spawn, Error};
use std::time::Duration;

fn main() -> Result<(), Error> {
    println!("Spawning ...");
    let mut p = spawn("cat")?;
    p.set_expect_timeout(Some(Duration::from_secs(3)));
    println!("Sending line ...");
    p.send_line("Hello World")?;
    println!("Expecting line ...");
    p.expect("Hello World")?;
    println!("OK!");
    Ok(())
}

If this program is run in GitHub Actions (using expectrl 0.6.0 and Rust 1.65.0), it succeeds on Ubuntu and macOS but fails on Windows; you can see such a run here. In particular, the output on Windows is:

Spawning ...
Sending line ...
Expecting line ...
Error: ExpectTimeout

On the latest commit at the time of writing

https://github.com/zhiburt/expectrl/blob/cbd01147d9977d2949a7f607bf424baa1daee168/tests/check.rs#L87-L106

To reproduce:

cargo test check_eof -- --exact

Test output on macOS 13 with zsh

running 1 test
test check_eof ... FAILED

failures:

---- check_eof stdout ----
thread 'check_eof' panicked at 'assertion failed: `(left == right)`
  left: `[]`,
 right: `[39, 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 39, 13, 10]`', tests/check.rs:103:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    check_eof

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 9 filtered out; finished in 0.62s

error: test failed, to rerun pass '--test check'

Hi, I'm trying to use expectrl to interact with a ssh password prompt on macOS (vers 12 if it matters) everything works but after the ssh session gets initialized the user input is not "printed" on the command line. Input is being passed to the ssh session, but it is invisible to the user. Example:

netadmin@CO-90062106: ______________<--- command is not visible

Desktop/ Documents/ Downloads/ Library/ Movies/ Music/ Pictures/ Public/

But it produces the expected return when return is pressed.

This code reproduces the issue

use expectrl::{check, spawn, stream::stdin::Stdin, Error};
use std::io::{stdout, Write};

fn main() {
    let command = format!("ssh netadmin@localhost");
    let password = "123xxx";
    let mut sh = spawn("bash").expect(&format!("Unknown command: {:?}", command));
    writeln!(sh, "{}", command).unwrap();

    println!("Now you're in interacting mode");
    println!("To return control back to main type CTRL-] combination");
    let mut stdin = Stdin::open().expect("Failed to create stdin");

    sh.expect("Password:").unwrap();
    sh.send_line(password).unwrap();

    sh.interact(&mut stdin, stdout())
        .spawn()
        .expect("Failed to start interact");

    stdin.close().expect("Failed to close a stdin");

    println!("we keep dong things");
}