test_read_line fails randomly

[petreeftime]

I was unable to reproduce the issue on my own. So far the only time it showed up is in https://github.com/philippkeller/rexpect/actions/runs/3060626462/jobs/4939368842, for PR #47.

I've reviewed the code involved in this test, but there was nothing obvious that could lead to such an issue. What I expected was that there's some sort of race condition where Session::read_line starts reading before the \n is available, and so it ends up reading the string once, stopping because it can't match and then reading again, but NBReader looks like it would correctly accumulate characters into the buffer and the whole operation is retried until the match is found in the buffer.

---- session::tests::test_read_line stdout ----
thread 'session::tests::test_read_line' panicked at 'assertion failed: `(left == right)`
  left: `"hans"`,
 right: `"hanshans"`', src/session.rs:438:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ekarlsn]

Before I changed the test expect_any. That would intermittently fail, giving "HiHi" instead of "Hi\r\n". I was able to reproduce that one locally.
Could it be something with the echo setting of the process?

[petreeftime]

This bug is super annoying. I don't know what to do to reproduce it. I tried to run it directly on my machine, inside an Ubuntu 20.04 VM, as well as trying to run it inside an Ubuntu 20.04 container, looping 1000x each, and it never reproduced for me. It must be something that's being caused by some configuration in the test env itself, possibly how it captures the output. I'll try to read into the TTY configuration parameters, maybe it something pops up.

[matthiasbeyer]

I will play around a bit in #75 ... lets see.

[petreeftime]

Looking at https://github.com/rust-cli/rexpect/blob/master/src/process.rs#L117, I think it would be better expressed as

flags.local_flags.remove(termios::LocalFlags::ECHO)

I don't think it should make a difference, ! and & on flags should do the right thing.