- Move CommandList so it can be used from more modules than
just ShellProcess
- Allow a CommandList to run itself. This centralizes
code for executing one or more commands and simplifies
the ShellProcess module.
Various small cleanups:
- mention instance id in log message
- code formatting / style
- Also allow a single string instead of a list
- Add count() method to CommandList
- Drop over-engineering, add more logging
- Expand tests with some more examples
This is basically dummyprocess, except with an expanded configuration
interface so you can run 1 or more shell commands in the live
or target system with a suitable configuration file and instance
of shellprocess in settings.conf.
It can replace downstream modules that implement their own
process modules with a command, by an instance of shellprocess.
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.
Make a function out of explaining-skipped-modules, and call it
not only after collecting all the modules, but also after
the feature summary, so that it's quite clear which modules
are skipped.
Scenario is this: you have no suitable installation devices on
your system (everything is mounted, or HDD has died), click through
to partition page, where you have all the buttons available, but no
devices in the list. The following actions then cause a crash:
- clicking "back"
- clicking any button
Prevent that:
- you can click "back", but if there is no device selected
nothing happens to the device state (no nullptr deref,
and no crash)
- button code is now more resilient to this scenario
- buttons are hidden until a device is available, so you
can't even click on them to trigger the code.
- remove hide-close-button hack
- refactor code in viewmanager for confirming quit
- hook up confirm-and-quit to WM close button
- also works for alt-F4 and other quit methods
- while here, update copyright year
FIXES#870
Modules may be skipped for different reasons: SKIP_MODULES
is the traditional approach to suppress some, but other modules
may have unmet build requirements (e.g. Plasma Look-and-Feel,
or the Partitioning module) and should be able to opt-out
of being built. For all those skipped, log it explicitly after
all the modules have been examined.
Only CMake-based (e.g. C++) modules support opting-out in this way.
This is meant to run one or more jobs based on specific global
configuration values; if could also be done by a Python
module with just some if's, but this one can be used with
just the config file and covers a bunch of use-cases.
The dummyprocess module can be used to run a single
shell command; it can be used effectively with instances
to run one or more commands during installation.
