rust-cli / rust-cli/rexpect

Performance differences between spawn() and spawn_bash()

Open
#93 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
391
Forks
69
Avg merge
1d 34m
Merged PRs (30d)
2

Description

Hello, this is perhaps not an issue, but I've been experimenting with the crate and notice the following behavior:

If I get a PtyReplSession with spawn_bash(Some(timeout)), and then use p.execute(command, ready), the time it takes for this to successfully return is directly related to timeout regardless of the time it actually takes command to reach ready. The higher the timeout, the longer it takes (but it returns Ok), and viceversa (though at a certain point, very small timeouts will fail to find ready).

If I get a PtySession with spawn(command, Some(timeout)), and then use p.exp_string(ready), the time it takes for this to successfully return is independent of timeout. I can change timeout as much as I want (as long as I don't make it too small), and the time to successfully return will remain constant. If ready is not found, the timeout works as expected.

I wouldn't expect the execution time of command to change when running in a PtySession vs a PtyReplSession. Could you explain why this happens? Is it a bug or am I missing something?

Example code with PtyReplSession:

let mut bash_session = spawn_bash(Some(10000))
.expect("session failed");

bash_session.execute("hostname", "mypc")
.expect("command failed");

Example code with PtySession:

let mut session = spawn("hostname", Some(10000))
.expect("session failed");

session.exp_string("mypc")
.expect("command failed");

Here are some test results:

Test: PtyReplSession with 2,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_repl_session_timeout_2000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 2.42s

Test: PtyReplSession with 10,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_repl_session_timeout_10000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 10.45s

Test: PtySession with 2,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_session_timeout_2000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.19s

Test: PtySession with 10,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_session_timeout_10000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.16s

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the reported timing with spawn_bash()/execute() and spawn()/exp_string(), using the two Rust examples and timeout values from the issue. Compare the PtyReplSession and PtySession paths, then add regression coverage showing that successful command completion does not depend on the configured timeout.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.