This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author San
Recipients San
Date 2021-07-22.16:00:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1626969626.94.0.722055319986.issue44709@roundup.psfhosted.org>
In-reply-to
Content
I was trying to wrap an old game server executable with a built-in console using Popen.

class ServerWrapper(Thread):
    def __init__(self, pathToExecutable: str, statusMonitor: Popen = None, active: bool = False):
        super().__init__()
        self.pathToExecutable = pathToExecutable
        self.statusMonitor = statusMonitor
        self.active = active

    def run(self):
        self.statusMonitor = Popen(['./bf1942_lnxded', "+statusMonitor", '1'], encoding='latin_1', stdout=PIPE,
                                   stdin=PIPE, cwd=self.pathToExecutable)
        while self.active:
            currentLine = self.statusMonitor.stdout.readline()
            if currentLine:
                print(currentLine)
                input('')

    def start(self):
        self.active = True
        super().start()

    def stop(self):
        self.active = False



I expected to be able to read the output line-by-line using enter, in a 'normal fashion'.
After importing this from a terminal and setting it up somewhat like so:

wrapper = ServerWrapper('bf1942')
wrapper.start()

However, once the server process started and thereby started writing to stdout, weird stuff started to happen to my shell with the python interpreter.

Apparently, there are control characters and ansi-escape codes sent from the process, that somehow manage to manipulate my shell if I specify an encoding. Consequentially the lines output with 'print(currentLine)' are reduced by these chars.

Is this the desired behaviour of the decoder? If so then I think this should potentially be further clarified in the documentation of Popen. I would have expected the chars to be escaped because the worst thing is, this happens even if you don't actually read from stdout at all. Seemingly the decoder executes incoming control sequences immediately (probably for the buffer?), regardless of if you actually bother to read the stdout or not.

The paragraph in https://docs.python.org/3.7/library/subprocess.html#security-considerations sounds like this shouldn't be happening if 'shell' is not set to 'True' at least.
History
Date User Action Args
2021-07-22 16:00:26Sansetrecipients: + San
2021-07-22 16:00:26Sansetmessageid: <1626969626.94.0.722055319986.issue44709@roundup.psfhosted.org>
2021-07-22 16:00:26Sanlinkissue44709 messages
2021-07-22 16:00:26Sancreate