We do not actually start a new Terminal process, so we need to clean up
the environment after the fact.
Clean the environment in the started shell except for some essentials,
read the config files as if for a login shell, and re-export the
environment.
There still can be differences, since environment variables set in the
user's bash profile etc will "win". This is wrong if we want to open the
terminal in anything but the "system environment", especially if the
PATH is effected, but I don't see how to solve that without severely
crippling the shell setup. This is also the current state on Linux.
Change-Id: I1d3c8184ac3bf543675e96f73253085fa6b1b29d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
By writing the needed special commands to a temporary file.
What we cannot get rid of is the command for opening a bash that sources
that file.
Since Terminal usually opens a login shell, but we cannot set a special
file for sourcing in that case, the special commands include mimicking
the behavior of a login shell by reading the corresponding config files.
This is in preparation to setting up the environment for the shell.
Since we do not start a new process for the Terminal on macOS, we will
need to explicitly export the whole environment after the fact,
resulting in potentially dozens of export commands to be executed.
Change-Id: Ia24cf1f00e62411734f5d6514d073e11d4cdae6e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This script will become even less trivial in the future, so use an
actually usable programming language for it.
Change-Id: I4fa1c8d327f97585bf8dde0ffaefc5fac7c1ca18
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Distinguishes the process that starts the terminal from the stub
process, as on mac to support Terminal.app they are different.
Handle the stub not through the process that starts the terminal,
but through the local socket (on *nix).
Replace the blocking wait(...) in the main thread, with a nonblocking
wait in the signal handler when receiving a SIGCHLD, to leave the
main thread able to handle communication with creator.
This change allows the use of terminal emulator commands
that share a single instance or that fork.
So this is also the real fix for QTCREATORBUG-1633 on linux.
If creator crashes the stub and the debugged program live on.
This was done on purpose, it could be changed if considered better.
Task-number: QTCREATORBUG-6371
Task-number: QTCREATORBUG-1633
Change-Id: I4d4fb3a67b1987f4e46e2c603dcefe8c15152ad2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
