mirror of
1
0
Fork 0
dotbot/dotbot/plugins/shell.py

79 lines
2.6 KiB
Python
Raw Normal View History

Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
import os
import subprocess
import dotbot
import dotbot.util
2014-03-19 23:07:30 -04:00
2016-01-16 22:00:15 -05:00
class Shell(dotbot.Plugin):
2022-01-30 18:48:30 -05:00
"""
2014-03-19 23:07:30 -04:00
Run arbitrary shell commands.
2022-01-30 18:48:30 -05:00
"""
2014-03-19 23:07:30 -04:00
2022-01-30 18:48:30 -05:00
_directive = "shell"
_has_shown_override_message = False
2014-04-24 15:41:34 -04:00
2014-03-19 23:07:30 -04:00
def can_handle(self, directive):
2014-04-24 15:41:34 -04:00
return directive == self._directive
2014-03-19 23:07:30 -04:00
def handle(self, directive, data):
2014-04-24 15:41:34 -04:00
if directive != self._directive:
2022-01-30 18:48:30 -05:00
raise ValueError("Shell cannot handle directive %s" % directive)
2014-03-19 23:07:30 -04:00
return self._process_commands(data)
def _process_commands(self, data):
success = True
2022-01-30 18:48:30 -05:00
defaults = self._context.defaults().get("shell", {})
options = self._get_option_overrides()
Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
for item in data:
2022-01-30 18:48:30 -05:00
stdin = defaults.get("stdin", False)
stdout = defaults.get("stdout", False)
stderr = defaults.get("stderr", False)
quiet = defaults.get("quiet", False)
Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
if isinstance(item, dict):
2022-01-30 18:48:30 -05:00
cmd = item["command"]
msg = item.get("description", None)
stdin = item.get("stdin", stdin)
stdout = item.get("stdout", stdout)
stderr = item.get("stderr", stderr)
quiet = item.get("quiet", quiet)
Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
elif isinstance(item, list):
cmd = item[0]
msg = item[1] if len(item) > 1 else None
else:
cmd = item
msg = None
if msg is None:
self._log.lowinfo(cmd)
elif quiet:
2022-01-30 18:48:30 -05:00
self._log.lowinfo("%s" % msg)
Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
else:
2022-01-30 18:48:30 -05:00
self._log.lowinfo("%s [%s]" % (msg, cmd))
stdout = options.get("stdout", stdout)
stderr = options.get("stderr", stderr)
Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
ret = dotbot.util.shell_command(
cmd,
cwd=self._context.base_directory(),
enable_stdin=stdin,
enable_stdout=stdout,
2022-01-30 18:48:30 -05:00
enable_stderr=stderr,
Work around subprocess.call() issue on Windows On POSIX-like systems, calling `subprocess.call()` with both `shell=True` and `executable='...'` has the following behavior: > If `shell=True`, on POSIX the _executable_ argument specifies a > replacement shell for the default `/bin/sh`. (via https://docs.python.org/3/library/subprocess.html?highlight=subprocess#popen-constructor) This seems to have a similar behavior on Windows, but this is problematic when a POSIX shell is substituted for cmd.exe. This is because when `shell=True`, the shell is invoked with a '/c' argument, which is the correct argument for cmd.exe but not for Bash, which expects a '-c' argument instead. See here: https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407 This is problematic when combined with Dotbot's behavior, where the `executable` argument is set based on `$SHELL`. For example, when running in Git Bash, the `$SHELL` environment variable is set to Bash, so any commands run by Dotbot will fail (because it'll invoke Bash with a '/c' argument). This behavior of setting the `executable` argument based on `$SHELL` was introduced in 7593d8c13479b382357be065c7bf51562a130660. This is the desired behavior. See discussion in https://github.com/anishathalye/dotbot/issues/97 and https://github.com/anishathalye/dotbot/pull/100. Unfortunately, this doesn't work quite right on Windows. This patch works around the issue by avoiding setting the `executable` argument when the platform is Windows, which is tested using `platform.system() == 'Windows'`. This means that shell commands executed by Dotbot on this platform will always be run using cmd.exe. Invocations of single programs or simple commands will probably work just fine in cmd.exe. If Bash-like behavior is desired, the user will have to write their command as `bash -c '...'`. This shouldn't have any implications for backwards-compatibility, because setting the `executable` argument on Windows didn't do the right thing anyways. Previous workarounds that users had should continue to work with the new code. When using Python from CYGWIN, `platform.system()` returns something like 'CYGWIN_NT-...', so it won't be detected with the check, but this is the correct behavior, because CYGWIN Python's `subprocess.call()` has the POSIX-like behavior. This patch also refactors the code to factor out the `subprocess.call()`, which was being called in both `link.py` and `shell.py`, so the workaround can be applied in a single place. See the following issues/pull requests for a discussion of this bug: - https://github.com/anishathalye/dotbot/issues/170 - https://github.com/anishathalye/dotbot/pull/177 - https://github.com/anishathalye/dotbot/issues/219 An issue has also been raised in Python's issue tracker: - https://bugs.python.org/issue40467 Thanks to @shivapoudel for originally reporting the issue, @SuJiKiNen for debugging it and submitting a pull request, and @mohkale for suggesting factoring out the code so that other plugins could use it.
2020-05-01 11:52:51 -04:00
)
if ret != 0:
success = False
2022-01-30 18:48:30 -05:00
self._log.warning("Command [%s] failed" % cmd)
2014-03-19 23:07:30 -04:00
if success:
2022-01-30 18:48:30 -05:00
self._log.info("All commands have been executed")
2014-03-19 23:07:30 -04:00
else:
2022-01-30 18:48:30 -05:00
self._log.error("Some commands were not successfully executed")
2014-03-19 23:07:30 -04:00
return success
def _get_option_overrides(self):
ret = {}
options = self._context.options()
if options.verbose > 1:
2022-01-30 18:48:30 -05:00
ret["stderr"] = True
ret["stdout"] = True
if not self._has_shown_override_message:
self._log.debug("Shell: Found cli option to force show stderr and stdout.")
self._has_shown_override_message = True
return ret