You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have not confirmed this, it is speculation. Also I imagine this could count as desired differences to the original expect, please clarify
I encountered a problem with trying to automate something over serial console. Pexpect seemed to be unable to find a pattern (here: a cli prompt after a quickly finishing command) and always ran into a timeout. I could imagine that this might be caused when the command output arrives with the prompt already at the end, if Pexpect matches something in the output and then, on the next search, doesn't start where the match ended but discards the whole buffer content that was already present when matching and waits for new data to come in to match against.
I looked around and I think this line might verify that hypothesis. Please explain whether you think this is really plausible.
Okay, I'm also on an old raspbian system and the pexpect version installed in quite old (4.2.1-1) so I almost expect this to be already fixed. Sorry, I'm apparently used to Arch now and being close to the actual development...
I'm all for Debian's (the distro Raspbian is based on) stable package releases but sometimes the actual upstream doesn't know about issues, this is why I recommend trying pip.
I installed with pip and am now on 4.8.0 - However, I got very inconsistent results up and run into timeouts with buffer and before being empty entirely. I need to add, I am interfacing with a device on serial console using minicom as the process, and found #317 which does remind me of my own problems. Sometimes it fails early, sometimes later, but currently it always runs into a timeout eventually.
Update: I switched from minicom to pyserial (coming from an ebook about expect I totally ignored the possibility of interfacing with a file descriptor instead of a process) and found some bugs in my code after all, as the results now were consistent again. Everything runs smoothly for me, finally.
This leaves only my initial suspicion about the code line. If it is a bug, it apparently poses no problem to me yet.
I have not confirmed this, it is speculation. Also I imagine this could count as desired differences to the original expect, please clarify
I encountered a problem with trying to automate something over serial console. Pexpect seemed to be unable to find a pattern (here: a cli prompt after a quickly finishing command) and always ran into a timeout. I could imagine that this might be caused when the command output arrives with the prompt already at the end, if Pexpect matches something in the output and then, on the next search, doesn't start where the match ended but discards the whole buffer content that was already present when matching and waits for new data to come in to match against.
I looked around and I think this line might verify that hypothesis. Please explain whether you think this is really plausible.
pexpect/pexpect/expect.py
Line 75 in f16add7
The text was updated successfully, but these errors were encountered: