This PR adds gorgeEx and staticReadEx which both return a tuple of output and result code. Furthermore, it add an optional parameter onErrorBreak to gorge and staticRead, because that was cheap to add when implementing gorgeEx functionality.
staticReadEx and gorgeEx will still break if executing the command raises an OSError.
This PR includes #4872.
So in what way #4871 is fixed? Any chance to note that in news.txt?
@yglukhov sorry, just saw that comment. The fix for #4871 has already been merged by #4872, so this seems to be the wrong place to discuss it. @Araq already documented it in the news.
I think this implementation is convoluted. Internally opcGorge can be changed to opcGorgeEx and a wrapper gorge can call gorgeEx. I'm also not too happy with this Ex naming convention.
@Araq: I had problems determining which proc was called without splitting opcGorge and opcGorgeEx. Not sure what and how you want it to be changed.
What would you prefer as name for the extended procs?
Tried to make code less convoluted
* moved common opcGorge[Ex] code to template
* renamed opGorge to opGorgeEx
* splitted opcGorge / opcGorgeEx implementations
Added gorgeEx test
Merge remote-tracking branch 'upstream/devel' into staticreadex
added system.gorgeEx that includes the exitCode; refs #4874; fixes #1994
Implemented it differently. Read and learn.