'Run a command on the remote host.
:arg cmd: byte string containing the command
:kwarg in_data: If set, this data is passed to the command\'s stdin.
This is used to implement pipelining.  Currently not all
connection plugins implement pipelining.
:kwarg sudoable: Tell the connection plugin if we\'re executing
a command via a privilege escalation mechanism.  This may affect
how the connection plugin returns data.  Note that not all
connections can handle privilege escalation.
:returns: a tuple of (return code, stdout, stderr)  The return code is
an int while stdout and stderr are both byte strings.
When a command is executed, it goes through multiple commands to get
there.  It looks approximately like this::
[LocalShell] ConnectionCommand [UsersLoginShell (*)] ANSIBLE_SHELL_EXECUTABLE [(BecomeCommand ANSIBLE_SHELL_EXECUTABLE)] Command
:LocalShell: Is optional.  It is run locally to invoke the
``Connection Command``.  In most instances, the
``ConnectionCommand`` can be invoked directly instead.  The ssh
connection plugin which can have values that need expanding
locally specified via ssh_args is the sole known exception to
this.  Shell metacharacters in the command itself should be
processed on the remote machine, not on the local machine so no
shell is needed on the local machine.  (Example, ``/bin/sh``)
:ConnectionCommand: This is the command that connects us to the remote
machine to run the rest of the command.  ``ansible_ssh_user``,
``ansible_ssh_host`` and so forth are fed to this piece of the
command to connect to the correct host (Examples ``ssh``,
``chroot``)
:UsersLoginShell: This shell may or may not be created depending on
the ConnectionCommand used by the connection plugin.  This is the
shell that the ``ansible_ssh_user`` has configured as their login
shell.  In traditional UNIX parlance, this is the last field of
a user\'s ``/etc/passwd`` entry   We do not specifically try to run
the ``UsersLoginShell`` when we connect.  Instead it is implicit
in the actions that the ``ConnectionCommand`` takes when it
connects to a remote machine.  ``ansible_shell_type`` may be set
to inform ansible of differences in how the ``UsersLoginShell``
handles things like quoting if a shell has different semantics
than the Bourne shell.
:ANSIBLE_SHELL_EXECUTABLE: This is the shell set via the inventory var
``ansible_shell_executable`` or via
``constants.DEFAULT_EXECUTABLE`` if the inventory var is not set.
We explicitly invoke this shell so that we have predictable
quoting rules at this point.  ``ANSIBLE_SHELL_EXECUTABLE`` is only
settable by the user because some sudo setups may only allow
invoking a specific shell.  (For instance, ``/bin/bash`` may be
allowed but ``/bin/sh``, our default, may not).  We invoke this
twice, once after the ``ConnectionCommand`` and once after the
``BecomeCommand``.  After the ConnectionCommand, this is run by
the ``UsersLoginShell``.  After the ``BecomeCommand`` we specify
that the ``ANSIBLE_SHELL_EXECUTABLE`` is being invoked directly.
:BecomeComand ANSIBLE_SHELL_EXECUTABLE: Is the command that performs
privilege escalation.  Setting this up is performed by the action
plugin prior to running ``exec_command``. So we just get passed
:param:`cmd` which has the BecomeCommand already added.
(Examples: sudo, su)  If we have a BecomeCommand then we will
invoke a ANSIBLE_SHELL_EXECUTABLE shell inside of it so that we
have a consistent view of quoting.
:Command: Is the command we\'re actually trying to run remotely.
(Examples: mkdir -p $HOME/.ansible, python $HOME/.ansible/tmp-script-file)'

@ensure_connect
@abstractmethod
def exec_command(self, cmd, in_data=None, sudoable=True):

    pass
