- In tests, a System object might be created without first
setting up a JobQueue. In that case, there's no instance,
so no GS to insert into. Avoid crash here.
- Calamares may need to create files in the target system;
provide a convenient API for doing so.
- This is mostly intended for small files with constant contents.
- This avoids processes that wait on stdin, and e.g. improves
reaction to having just "cat" (no file) in a command, or
a package manager that asks for input.
- JobQueue is only needed to get global settings, which are needed
when running in the target; for host commands, allow running
without a queue.
- Settings is needed for the value of debugsettings; assume if
there's no settings object, that we're in a test and should
print debugging information.
- This is the same as EFAIL: a block is indented as if it's a multi-
line else block. This isn't Python though, and the return always
applies.
- Add the necessary braces.
- Apparently noone uses this code path (until ProcessJob was re-
factored to do so).
- Replace magic numbers like -3 with named enum values
(NoWorkingDirectory, for -3).
- Downside is big-ugly static_casts, but that's what you get
for having an int as return value for processes.
- Don't insert a space before the output of a process
- To do this, suppress space and quoting on the output, and to do
that move the labeling-output for warnings and errors into
the constructor (so that an idiomatic .nospace() does the right thing).
- The Python testmodule script can end up calling in to System
methods (via System::instance()). This is unusual, and the
System instance has not been created at that point.
Now, create an instance and warn about it.
These additional pointers were introduced for translations,
and needed their own tricks to get lupdate to recognize the
strings. Using QCoreApplication::translate() removes the
need to a QObject to provide context. Drop the now-unneeded
parameters.
Instead of using tr and some macro hacks to get lupdate to
recognize the translation, instead use QCoreApplication::translate()
which takes its own context for translation.
Back targetEnvCommand() with a more general runCommand()
that takes an argument selecting the location to run
the command in. This allows us also to use the same
API for running processes in the host during install,
as we do for running them in the target system.
One reason for this change is wanting to run (user-specified)
commands and independently from the global dontChroot setting,
run those commands in the live system or the target.
This changes the ABI of the DLL, since targetEnvCommand()
is no longer exported. Plugins will need to be recompiled.
- refactor targetEnvCommand() into more general runCommand().
- While here, allow host system commands to run even if
there is no global storage.
- provide convenience accessors for ProcessResult members
- Move explanation of process errors out of ProcessJob
- Move from ProcessJob to ProcessResult, so it can be
reused outside of ProcessJob (e.g. from ShellProcessJob).
- Add some convenience functions, too.
- Add a more general targetEnvCommand() that returns both
error code and process output.
- Change existing targetEnvCall() and targetEnvOutput()
to use general form while discarding some data.
