It's internal method, not meant to be used outside.
It's only used in case of FailedToStart error.
Remove it also from ProcessInterface.
Leave it inside DefaultImpl and its subclasses only.
Remove m_errorString field from ProcessSetupData.
Change-Id: Ie605b95c2ff605ab1259045f1a5b16049207c1d3
Reviewed-by: hjk <hjk@qt.io>
I find it too confusing to have that inheritance only to enforce
similar interfaces.
Change-Id: I9da68ea59c04f709228e0874460e987115b30f56
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't detect a call to QtcProcess::kill() from inside the
QtcProcess callback while awaiting inside QtcProcess::waitFor...().
That's not needed, since a call to kill() sends a stop message
to the process launcher, so we wait for confirmation
from process launcher instead. This may bring e.g. new
read data from the running process.
Fix a runBlockingStdOut() test so that when we write to the stdOut
from the running process we flush the unfinished line so that
it's not buffered inside the process.
Change-Id: I7944ac214d8cb9e10a71715a7ef8bfacab6df7c9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
...instead of ensuring in many functions that m_setup isn't null.
This amends 36c49cd2ea and
solves the issue for other functions like processId(),
exitCode(), etc...
Amends 36c49cd2ea
Change-Id: I986f7b30e90e5825ae2bb57b4bc2aa14f56e401f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
ProcessProxyInterface will be helpful when implementing
public subclasses of ProcessInterface, like
general ssh impl, linux specific impl, qnx specific, etc.
ProcessProxyInterface is sharing private data
between proxy and target.
Change-Id: I8350837bb5f770d6605b860b146604cba5e6b592
Reviewed-by: hjk <hjk@qt.io>
Introduce private DefaultImpl class and base QProcessImpl
and ProcessLauncherImpl on it. Remove default impl specific
methods from ProcessInterface.
Change-Id: Iea964ab19cc0ea8401180f65351b6ef3f595703f
Reviewed-by: hjk <hjk@qt.io>
Introduce emitStarted, emitFinished and emitErrorOccurred
virtual protected methods for QtcProcess subclasses.
It makes it easier to connect to self signals and
filter out the unneeded emissions. This is a temporary
change until QtcProcess is de-virtualized.
Amends ff68923846
Change-Id: I784676458e86314e092366e3b3b1244dfe2712f3
Reviewed-by: hjk <hjk@qt.io>
Always write the process number on the same column of "started" and
"finished" line, for easier reading.
Do not quote the command line.
Write out only count of bytes for stderr (like for stdout).
Add extra logging categories qtc.utils.qtcprocess.stout and *.stderr for
verbose outpout.
Add the elapsed time in ms to the "finished" line.
Change-Id: I493279c1b4cdaf8f4c292df4777befc7f6c50753
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Call new hook from inside QtcProcess::start().
This hook calls new virtual method
IDevice::createProcessInterface().
That's all what should be needed from device
to setup properly device specific process.
Make QtcProcess::createProcessInterface() private now.
Change-Id: I2136698063bafc846ebc2d3db6cc11376902eff0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Make ProcessInterface c'tor accept nullptr as parent.
Remove parent argument from subclasses of
ProcessInterface, as calling setProcessInterface()
sets the parent anyway. Fix parent-child relationship
in subclasses of ProcessInterface - pass *this as a parent.
Change-Id: I3c37c305a87bad0e6d11251ec3db538f3a5dd64b
Reviewed-by: hjk <hjk@qt.io>
After removing Runnable parameter from DeviceProcess::start()
(see 95c9579c58) we are now
setting the runnable's environment to the remote process
directly. This is now used in 2 places:
1. For forming the proper fullCommandLine(), so that
the passed environment is expanded to command line
arguments
2. For running the remote process itself.
Before the mentioned change these two environments were
separated (1st was taken from run environment aspect,
2nd was left with its default value - see SshProcess c'tor).
After the mentioned change 1 and 2 are equal (i.e. both are
env aspect). This affects running app in terminal,
as the aspect env is applied to the stub process, so it
can't start properly.
This change brings the separation back.
Amends 95c9579c58
Change-Id: I5efe82e19d3fb5608f97e56c2f4b7651643e156a
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Drop it also from registerHandle() methods, as it wasn't
used there.
Change-Id: I34b72c38368b82f22d73314fe3cd429ed43cadbc
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
That makes it easier to understand which result belongs to which
process. And make the result output a 1-liner in the case of logging,
which makes filtering easier.
Change-Id: I6da84d28fe2269d2d6dfe6f5a1d300faf5697ca1
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
SshDeviceProcess::start() is overridden and it starts
connecting phase. It marks the current state as
Starting. Later, when connection is being established,
it calls back the base QtcProcess::start() and it
fails on assert. This doesn't happen when starting
not in terminal, as in this case SshDeviceProcess
delegates the start to the aggregated SshRemoteProcess
instead of calling QtcProcess::start().
Disabling the assert for a while, until we de-virtualize
the public interface back again, as from the public
API side it's still a valid assert.
Change-Id: I0d62ec0db778f68fcc5afa4a6f08d54f98d74e4f
Reviewed-by: hjk <hjk@qt.io>
Add an info to the start process log about whether it was
started by a call to QtcProcess::runBlocking() or not.
In case it was, specify the event loop mode.
Change-Id: Ie1adf0526b341eedcd0d84505075a942b057ff99
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Also simplify the wording of a message.
Task-number: QTCREATORBUG-27055
Change-Id: I29df31f8484d451d8d8d1869ca3a1b182072d2c1
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Since the input data may have changed in meantime.
Ensure we are not running when restarting the process.
Change-Id: I79a515b3c0526a6315027433fd821698fb2c6e94
Reviewed-by: hjk <hjk@qt.io>
Get rid of program and arguments parameters from
start() method. Get rid of customStart() and isCustomStart()
methods. Provide a default implementation for start() method.
Introduce virtual doDefaultStart() method, to be called when
default implementation for start() is used() - it's being
triggered by a call to defaultStart(). When some implemetation
provides the custom implemetation of start() method
(e.g. TerminalImpl), the doDefaultStart() may stay unimplemented
(won't be called).
Rename WrongFileNameFailure to WrongCommandFailure, as that's
being used also in case when command arguments parsing failed.
Cleanup some unimplemented or unused fields of ProcessLauncherImpl.
Change-Id: I87661e9838dc30888034b2fa62d47c861bf8f9dd
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Don't pass writeData, as that's available through
ProcessSetupData.
Change-Id: Ic55b21c6a3338168ee251bcc1c57594f50c52d2f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Don't share the same instance of data with the QtcProcess
itself, as some of the fields needs to be modified just
for the starting purposes. In this way we avoid cyclic
modifications of the original data on subsequent runs.
Change-Id: I937978ee92f848d247025939ac5b0c6c60c29ff7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Use Utils::Environment for of environment.
Use Utils::FilePath for workingDirectory.
Change-Id: I6b717139f8ff7ddbd629fb22cf816b2303fb5e6a
Reviewed-by: hjk <hjk@qt.io>
This includes replacing DeviceProcess terminal handling with base
member.
Change-Id: Id1541bfce33c71dddc71b4816ad0b174dce3879c
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
I'd really like to keep/re-enable at least the terminal use
as kind of property not directly tied to the QtcProcess object
life time.
This here is a first step towards this goal (and only a sketch)
I am not sure whether I like using a pointer to a "parent"
data struct as a means to propagate data, but it works, and
it's easy to add a new data item without touching all lower levels.
Change-Id: Ice2d3246951438a14383b097f307fd61306c29db
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
