summaryrefslogtreecommitdiff
path: root/src/plugins/python/pythonlanguageclient.cpp
diff options
context:
space:
mode:
authorJarek Kobus <jaroslaw.kobus@qt.io>2022-03-17 02:14:41 +0100
committerJarek Kobus <jaroslaw.kobus@qt.io>2022-03-21 11:32:31 +0000
commitc94564d910f653e97e201c25006e8b78bd07a8d4 (patch)
treee9c2518172cfa7ae19d85987ef0c1ce21b3906a8 /src/plugins/python/pythonlanguageclient.cpp
parent162fc2708c56c916e0d788aa2ffaabba908830bf (diff)
downloadqt-creator-c94564d910f653e97e201c25006e8b78bd07a8d4.tar.gz
LinuxDevice: Get rid of a marker for outputForRunInShell()
Don't rely on a synthetic marker when running a shell command and expecting any output. The marker might always be a part of the output data from the running command. That's unreliable. A solution is to do a similar thing that we are doing inside runInShell(). We ignore the error channel there, so it means that when calling outputForRunInShell() we have two channels for our purposes. So, the output from the command we pass through, and its error channel we redirect to /dev/null. Later, we run "echo $?", which prints the return code from the last command and we redirect it to standard error channel. Inside outputForRunInShell() we read the error channel as long as we detect something there. We assert if it's being convertible to int and we also assert that the command itself succeeded. Afterwards we break the endless loop and read the output channel for the first time - it should contain all the output gathered from the running command. Change-Id: Ia0ad73623f813ef593c11dff9bdba4df9e524315 Reviewed-by: hjk <hjk@qt.io>
Diffstat (limited to 'src/plugins/python/pythonlanguageclient.cpp')
0 files changed, 0 insertions, 0 deletions