Make Environment a stack of changes that gets "expanded" to
a full environment before things are actively accessed.
Later this expansion should be done lazily if possible.
Task-number: QTCREATORBUG-28357
Change-Id: If1c7bfdb9f58b81e71c51ed87ee75d6964a47019
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Previously DesktopDevice::openTerminal used custom code to open a
terminal window. This patch changes it to use QtcProcess with
TerminalMode::On.
This also removes the need for "openTerminal.py" on macOS.
Change-Id: Iec978bdd19487ff8e59dcd88c35c2d01b0681022
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
[ChangeLog][RemoteLinux] Target-side shell profiles are not sourced by
default anymore.
Change-Id: Ide5029d02a0d149c4e532ee523f1dd49e7080c7b
Reviewed-by: hjk <hjk@qt.io>
Make Pty::Data optional. When set, the PtyProcessImpl
implementation is implied.
Change-Id: I7990e9d9016223e6597d876a5d0c4ed177365874
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
* Combined local and ssh process list retrieval into LocalProcessList
* Combined QnxProcessList into LocalProcessList
* Renamed LocalProcessList to ProcessList
Change-Id: I230c575375e306c638e4ca3034fa2d7ed243a44c
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Integrating PtyQt directly into QtcProcess allows us to
start Pseudo terminal processes using the existing QtcProcess
functionality such as starting remote process on e.g. docker
or remote linux devices.
This is needed for the new Terminal plugin.
Change-Id: Iaeed5ff9b341ba4646d955b2ed9577a18cd7100f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Enforce setting a shell to start based on whether environment variables
might be set.
Fixes: QTCREATORBUG-28738
Change-Id: Ic43f0057bc89410e3146bafa2b109f472e01aa3b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Adds the option Environment::combineWithDeviceEnvironment. This allows
the linuxdevice to set it to false.
Without this option a deadlock would occur when the QtcProcess tries to
get the device environment and the device shell failed to start.
(e.g. because a required command is missing on the device).
Change-Id: I8f7550d0d90e989a339f27e993a836e67e910e33
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
In order to conform to the theory: "Removing all
QTC_ASSERTs and QTC_CHECKs should not change anything".
Change-Id: I3f544f8cdcede99d7efa3ba0ef456180203c45be
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
... and re-use the old QtcProcess::readAllStandard* names for
a QString-returning 'decoded' version.
For now, only use that in 'full Utf8' cases, to stay bug-compatible,
the plan is, however, to employ the QTextCodecs we have already
in the channel buffers. That will be one-by-one, though.
Change-Id: Id209e0671920d4ea4197918e872f441254112d52
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... when changes to the environment are requested.
Ideally, that should be the user's chosen shell on the device,
but ssh does not support the case of specifying shell variables
without also giving an executable.
Short of playing tricks with /etc/passwd, getent, or env, use
/bin/sh which is guaranteed to exist.
Change-Id: I8d4b87f2a94eb9614d85dcacebd539ac645dc33d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Easier nowadays. It's synchronous now, so conceptually worse,
but 'env' is not worse than 'ls', and this is used regularly
all over the place also for larger data sets without being a problem.
Change-Id: I2c2b1db8c07ff5c128700d4a1deefd710967568a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is just a workaround for 9.0 and not a proper fix!
It looks like sometimes kill command may freeze. Don't blocking
wait for it for 30 seconds - limit this time to 2 seconds.
Do the same inside SimpleTargetRunner. Pretend the process
finished after 2 seconds, otherwise the SimpleTargetRunner
object gets leaked and we start receiving asserts from
ProcessLauncher about destructing it when still some processes
are being run.
Task-number: QTCREATORBUG-28072
Change-Id: I9766e7ff6f0c2abf2010686027702d30d32c4318
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
It looks like starting device shell is fragile in some
circumstances.
Fixes: QTCREATORBUG-28072
Change-Id: I1a51d1fb939bd42884a55e1492de808bee89219f
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Before, the SshProcessInterface was trying to run kill
command (on remote host) for the running processId. However,
in case of terminal process the returned processId is an id
of ssh running through creator process stub, not the id of
remote process. The fix is to redirect a call to sendControlSignal
into the internal terminal process.
Change-Id: I57509fd61a54c335ab0a34f8ca0dffb3d75da696
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Removed also some other includes that were marked
with yellow triangles. In some cases includes of
runcontrol.h were substituted with other includes,
like qtcassert.h.
Change-Id: Ica40f68198c7f8f70e6047acb2eddc8ef017e43d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
By using a generic file transfer method based of FilePath::copyFile()
that doesn't require either of the transfer end point to be the
local host.
Change-Id: Ia2e4273df52f5ce6533046d96be3f6b521b7f0a5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The change of runInShell to take QString + QStringList meant
that the caller was no longer able to fine tune the argument
escaping. This lead to "find -exec ... \;" being escaped incorrectly.
Changing back to CommandLine fixes this.
Change-Id: I55b09bd745c09912a2a0b4e43432824a99c0dd4e
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The file accessing functions form now a class hierarchy by themselves,
the devices return a suitable point.
The previous implementation was mildly confusing by the special handling
of the DesktopDevice, fallbacks and remote cases in the same function
leading to unnecessary boilerplate when adding new functions and
codepaths that sometimes passed the FilePath API twice.
Implemented are a "DesktopDeviceFileAccess" taking care of the
previous !needsDevice() branches and a "UnixDeviceFileAccess"
covering the current docker and RL uses.
As a side-effect this unifies to a large degree the current docker
and RL code paths with were occasionally deviating from each other
while they shouldn't.
Change-Id: I4ff59d4be2a07d13e2ca5e9ace26a84160a87c9d
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
::filePathInfo and iterateDirectory(..., IterateDirWithInfoCallback, ...)
allow for faster info retrieval by the fsengine, making the listing
of large directories like /bin a lot faster.
Change-Id: I2a21e019e05f5bb08459483747ba2be4530929f4
Reviewed-by: hjk <hjk@qt.io>
Use QFile::seek to implement locally and a dd seek based poor man's
implementation on RL and docker.
Change-Id: I241d1c34c00e991845d132ad8edefa1377ba1311
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Pass on stderr data and exit code to the caller, it's typically
in a better condition to handle errors.
Use it to notify the user about non-available 'find' arguments
and fix the fallback to ls-based operation.
Change-Id: I535535de2ffa09cad1dd6e9b07eb69f807dbae2f
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: hjk <hjk@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
... by setting QTC_ALLOW_REMOTE_LINUX_BUILD_DEVICES=1
Registering compilers and cmake on such devices already
works manually. [Note: The remote file dialog is extremely
slow when browsing remote directories]
After that, opening a CMakeLists.txt on the device works,
but not much more.
Change-Id: I19025930699f6aec57d26a36b3fb04109fbf03e8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
