Minor optimization of fix_utf8()

[ideal]

Since decode_output() will not raise UnicodeDecodeError, there is no need to catch that.

[techalchemy]

Thanks for the PR!

this change seems to optimize away a code path that is still very possible to hit, so we probably would want to keep the code in question for now

[techalchemy]

What leads you to believe this is not a possible code path? The above code block always attempts to encode the provided text into the desired encoding without any regard for what that encoding is; it might encode it to ascii for example, or mbcs. It is still very capable of raising this error:

>>> decode_output("✗ FAILED")                 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 13, in decode_output
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal not in range(128)
                                                                                                                                 
'ascii' codec can't decode byte 0xe2 in position 0: ordinal not in range(128)

[ideal]

Thanks. Previously I thought UnicodeDecodeError is already caught and it will be processed via vistir.misc.to_text() or output.translate(). Am I wrong?

Also I can not reproduce your problem, with python 2.7.17:

>>> "✗ FAILED".encode("utf-8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal not in range(128)
>>> decode_output("✗ FAILED")
u'\u2717 FAILED'

decode_output() does not raise UnicodeDecodeError, is it related with locale setting or terminal setting? Thanks again.

[techalchemy]

hrm... I swapped computers since yesterday and I can't reproduce it here; I suspect this relates in some way to #3131

[techalchemy]

Since I think we can still encounter this I am going to close this PR for now. I do feel this code has significant room for improvement but we should be careful not to accidentally break python 2 workarounds in the interim

Thanks again for taking the time to dig into this, I'm pretty sure there are pieces of the terminal output encoding puzzle we can unravel a bit to improve the codebase for anyone willing to dive in