Travis (edit: Linux) environment triggers bad behavior when pty=True

[bitprophet]

Example: https://travis-ci.org/pyinvoke/invoke/jobs/63565360 - note that the issue here is the "outer" Invoke run executing the regular tests, and then what looks like the same issue popping up inside of the integration tests (and then again outside of them in that outer Invoke session. This dogfood is rancid!)

There's actually two things here, one of which is distinct (the thread args containing the mutated buffer arguments, which is thus really useless for debugging purposes) and one that is actually important (the fact that the IO threads are yielding OSErrors for no apparent reason).

Currently trying to run the tests on a Linux VM in case it is simply a platform issue. Otherwise it gets to be "run Travis over and over" happy fun times.

[bitprophet]

Confirmed I can recreate it on Linux, phew. Pokin' time.

[bitprophet]

Did ef8741afba23d4fe8cd538d938816e86821781fd which makes the thread errors not disturbingly large, at least.

Also confirmed that a trivial base case of just c.run('echo whatever', pty=True) triggers the error, so it's not even related to large/complex/ANSI-bearing/etc output. Which is what I expected, feels like a timing issue or perhaps one of those terminal mode bits we haven't ported back from pexpect yet.

[bitprophet]

I knew this felt familiar, it must be #37 again - I removed it in fdaedf5513438a232b2a1aa7c832d4dcb74f72f2 because I wasn't experiencing it locally with the post-pexpect code & thought it was pexpect-specific. It hasn't been in force the whole time since that commit, going by Travis history, so perhaps something I did recently triggered it - will bisect real quick.

[bitprophet]

Bisect implies it really did start breaking once we first went down the custom pty module-using road. Real strange. Doesn't really change anything though, just going to try reapplying the solution for #37.

[bitprophet]

All done.