Execute a shell command via ``sudo`` with password auto-response. **Basics** This method is identical to `run` but adds a handful of convenient behaviors around invoking the ``sudo`` program. It doesn't do anything users could not do themselves by wrapping
(self, command: str, **kwargs: Any)
| 129 | return runner.run(command, **kwargs) |
| 130 | |
| 131 | def sudo(self, command: str, **kwargs: Any) -> Result: |
| 132 | """ |
| 133 | Execute a shell command via ``sudo`` with password auto-response. |
| 134 | |
| 135 | **Basics** |
| 136 | |
| 137 | This method is identical to `run` but adds a handful of |
| 138 | convenient behaviors around invoking the ``sudo`` program. It doesn't |
| 139 | do anything users could not do themselves by wrapping `run`, but the |
| 140 | use case is too common to make users reinvent these wheels themselves. |
| 141 | |
| 142 | .. note:: |
| 143 | If you intend to respond to sudo's password prompt by hand, just |
| 144 | use ``run("sudo command")`` instead! The autoresponding features in |
| 145 | this method will just get in your way. |
| 146 | |
| 147 | Specifically, `sudo`: |
| 148 | |
| 149 | * Places a `.FailingResponder` into the ``watchers`` kwarg (see |
| 150 | :doc:`/concepts/watchers`) which: |
| 151 | |
| 152 | * searches for the configured ``sudo`` password prompt; |
| 153 | * responds with the configured sudo password (``sudo.password`` |
| 154 | from the :doc:`configuration </concepts/configuration>`); |
| 155 | * can tell when that response causes an authentication failure |
| 156 | (e.g. if the system requires a password and one was not |
| 157 | configured), and raises `.AuthFailure` if so. |
| 158 | |
| 159 | * Builds a ``sudo`` command string using the supplied ``command`` |
| 160 | argument, prefixed by various flags (see below); |
| 161 | * Executes that command via a call to `run`, returning the result. |
| 162 | |
| 163 | **Flags used** |
| 164 | |
| 165 | ``sudo`` flags used under the hood include: |
| 166 | |
| 167 | - ``-S`` to allow auto-responding of password via stdin; |
| 168 | - ``-p <prompt>`` to explicitly state the prompt to use, so we can be |
| 169 | sure our auto-responder knows what to look for; |
| 170 | - ``-u <user>`` if ``user`` is not ``None``, to execute the command as |
| 171 | a user other than ``root``; |
| 172 | - When ``-u`` is present, ``-H`` is also added, to ensure the |
| 173 | subprocess has the requested user's ``$HOME`` set properly. |
| 174 | |
| 175 | **Configuring behavior** |
| 176 | |
| 177 | There are a couple of ways to change how this method behaves: |
| 178 | |
| 179 | - Because it wraps `run`, it honors all `run` config parameters and |
| 180 | keyword arguments, in the same way that `run` does. |
| 181 | |
| 182 | - Thus, invocations such as ``c.sudo('command', echo=True)`` are |
| 183 | possible, and if a config layer (such as a config file or env |
| 184 | var) specifies that e.g. ``run.warn = True``, that too will take |
| 185 | effect under `sudo`. |
| 186 | |
| 187 | - `sudo` has its own set of keyword arguments (see below) and they are |
| 188 | also all controllable via the configuration system, under the |
no test coverage detected