avocado.utils.process: Rename SubProcess.sp to SubProcess._popen

The reasoning here being that we don't want this part of
the public API. We don't need users to interact directly
with the Popen object, since the interaction will be
done by means of the public methods.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.utils.process: Move subprocess initialization to public method calls

Currently, as soon as we initialize a process.SubProcess
object, a subprocess.Popen() object is created. This breaks
the user's expectation that the process will start when
run() is called. Therefore, move process execution to
a private method, and call that method in all public
methods of the class.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.utils.process: SubProcess() -> Add .start() and .stop() methods

Now that we do not initialize the subprocess upon class
initialization, add a utility method .start(), that will
start running the command, useful for background commands.

In order to make things symmetrical, add a .stop() method,
that will send a sigterm to the process, then wait on it.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.utils.process: Introduce shell option to process APIs

After observing some racing conditions related to the execution
of processes on sub shells, step back and provide users
the ability to chose whether they want their command to
be executed in a subshell (in most cases, you'll want it
only if you want to use shell constructs such as pipes in
the resulting command).

Add the param shell to the SubProcess constructor (shell=False),
and modify avocado to use shell=True in the few commands that
actually require it.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.utils.process: SubProcess -> Add .__repr__() method and reorganize __str__()

In order to show more clearly process information, add
a __repr__() method, and modify __str__() to the SubProcess
class.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
selftests: Add functional tests for SubProcess.

Add functional tests for the class avocado.utils.process.SubProcess,
regarding the methods start() and run().

Even we already use it for other tests, we must have
tests for this own basic feature.

Signed-off-by: Rudá Moura <rmoura@redhat.com>
Merge pull request #252 from lmr/process_init_on_demand_v5

[V5] Process init on demand
avocado.utils.process: add support for environment variables.

The main SubProcess class now supports an argument (env) to receive
extra environment variables to the subprocess execution.

Note that it's extra in the sense that it includes the
current environment variables, so the previous environment is
not destroyed.

The utility functions now accepts this extra environment variables.
It's more robust to pass variables as a dictionary than
using the shell feature of shell variables.

Signed-off-by: Rudá Moura <rmoura@redhat.com>
avocado.utils.build: Don't use shell feature to pass environment variables.

Don't use the shell like feature to pass environment variables
to the make command, instead of make use of the new feature
in module avocado.utils.process to pass environment variables.

Plus make use of argument make to define the make command name.

Signed-off-by: Rudá Moura <rmoura@redhat.com>
examples.tests: Don't use shell feature to pass environment variables.

Don't use the shell like feature to pass environment variables
to the make command, instead of make use of the new feature
in module avocado.utils.process to pass environment variables.

Signed-off-by: Rudá Moura <rmoura@redhat.com>
Merge pull request #253 from ruda/subprocess_with_env

Include support to add extra environment variables in module `avocado.utils.process`.