Added \r\n to the expect() string as recomended at:
http://pexpect.readthedocs.io/en/stable/overview.html#find-the-end-of-line-cr-lf-conventions
this should work on both windows and linux systems
pexpect says it will always do a minimal (non greedy) matching and docs explicitly say that a .+ expression will always return only one character. These lines in autotest are looking for \S+, which, believing the documentation, would only return one character of the log file path.
Now we know that's not true, neither for Linux or for Windows (given the logs from @karthikdesai), so I can only assume that it does a greedy match but only for the characters it has received at the time expect is called.
Apparently, in the machines we are using autotest, it isn't a problem since MAVProxy is likely fast to give its output to pexpect before the expect method is called. On @karthikdesai's machine that wasn't happening since his machine was more or less loaded.
Concluding, this looks like a correct fix in the sense that it extends the regex pattern to wait for the end of line (and probably other places could benefit from it too).
Based on work done by khancir
(https://github.com/ArduPilot/ardupilot/pull/6360)
Tools: arduplane.py change print to progress function
Tools: quadplane.py change print to progress function
Tools: ardusub.py change print to progress function
Tools: TestAutotune.py: Fix undefined name VehicleType
__VehicleType__ is used on line 58 but is never defined or imported.
Tools: TestPerformance.py: Fix undefined name VehicleType
__VehicleType__ is used on line 19 but is never defined or imported.
Tools: TestParams.py: Fix undefine name VehicleType
__VehicleType__ is used on line 21 but is never defined or imported.
Tools: TestThrust.py: Fix undefine name VehicleType
__VehicleType__ is used on line 19 but is never defined or imported.
Tools: TestVibration.py: Fix undefined name VehicleType
__VehicleType__ is used on line 21 but is never defined or imported.
__lit.next()__ is not Python 3 compatible but __next(lit)__ is compatible with both Python 2 and 3.
In Python 2.6 and later, it is safe to merely switch from lit.next() to next(lit). See: http://python3porting.com/improving.html#the-next-next Both the automated tools 2to3 and futurize consider this "fixer" to be a "safe" change as we saw in #6954
Peter Barker
HeBin
Dr.-Ing. Amilcar Do Carmo Lucas
Andrew Tridgell
Patrick José Pereira
murata
Jacob Walser
Pierre Kancir
ravsrivera
uavdlsu
marcsay
guglie
el-shweikh
TsuyoshiKawamura
Staroselskii Georgii
Gabriel Moyano
cclauss
Lucas De Marchi