Py3: decode subprocess output

[Gnarlodious]

Under Python 2.6, commands.getoutput returns text type str containing
ANSI Terminal formatting hex characters:

"\x1b[1;31mSun : \x1b[1;36m114.902\x1b[0m - 0\xf800' (-)\x1b[1;33m

I have a system for parsing out the relevant parts and I prefer to
keep using that system.

Under Python 3, subprocess.check_output returns a bytestring that
doesn't parse. Since the CLI program (written in the 1990's) will
never send Unicode, is there a way to downconvert the bytestring into
type str so as to emulate Py2.6 behavior?

Or alternatively, is there a whizbang Py3 method to parse out strings
delimited by hex? I tried several tricks but it is all beyond my
skills.

Thanks.

-- Gnarlie

 

[Martin v. Loewis]

Under Python 3, subprocess.check_output returns a bytestring that

doesn't parse. Since the CLI program (written in the 1990's) will
never send Unicode, is there a way to downconvert the bytestring into
type str so as to emulate Py2.6 behavior?

What do you mean by "that doesn't parse"? Returning a byte string is
*already* emulating 2.6's behaviour: in 2.6, you also get a byte string,
and most likely the very same string.

Or alternatively, is there a whizbang Py3 method to parse out strings
delimited by hex? I tried several tricks but it is all beyond my
skills.

Please understand that there really aren't "hex characters" here. Each
individual character is a byte, i.e. "Sun" == "\x53\x75\x6d". So the
strings you get aren't delimited by a "hex character", but by a "control
character".

That said: how did you try to parse it, and how did that fail?

Regards,
Martin

 

[Tim Harig]

Under Python 3, subprocess.check_output returns a bytestring that
doesn't parse. Since the CLI program (written in the 1990's) will
never send Unicode, is there a way to downconvert the bytestring into
type str so as to emulate Py2.6 behavior?

str() will convert a bytestring into a Python string object which you will
be able to parse so long as the output remains ASCII (which your example
is). If the input uses another encoding or contains characters with the
high order bit set, you might need to fiddle with the strings encoding.

 

[Gnarlodious]

OK, it turns out I had to tweak the parsing minimally for Python3:

1) Substrings such as st[5] no longer work (returns an ascii number),
instead st[5:6] selects one character

2) Replacements need to specified as bytes: s.replace('R','*') change
to s.replace(b'R',b'*')

So I think this problem is solved.

-- Gnarlie