This forces Dotbot to produce colored output, regardless of whether it
is outputting to a TTY.
This is useful to support use cases such as piping colored Dotbot output
into another program for formatting (e.g. I want to indent the output as
part of a larger installation script); this was not previously easy to
do as this would cause the output to lose its colored formatting.
This option cannot be provided at the same time as the existing
`--no-color` option, as there's no logical interpretation of what effect
providing both of these should have.
As part of this change I've refactored some existing code determining
whether output should be colored to where options are parsed, as this
made this change simpler and I think it makes sense for all this logic
to be performed in the same place.
In the setup guide in the README, we have people start out with an empty
file (created using `touch`). Before this patch, Dotbot gave the
following error:
Configuration file must be a list of tasks
Instead, with this patch, Dotbot says:
Configuration file is empty, no work to do
This change was prompted by
https://github.com/anishathalye/dotbot/pull/226.
This patch adds parameter/explanation tables for the two other commands
that support extended configuration syntaxes, so now we have
identically-formatted tables for link, shell, and clean.
This change was prompted by
https://github.com/anishathalye/dotbot/issues/223.
Without an explanation of what's going on here, this example is
unnecessarily confusing. It's a neat example, but probably not worth
explaining this in Dotbot's README.
See https://github.com/anishathalye/dotbot/issues/224.
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:
1def7754b7/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 7593d8c134. 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.
Dotbot had a hardcoded behaviour that the BASEDIR was always passed to
os.path.realpath which "returns the canonical path of the specified
filename, eliminating any symbolic links encountered in the path".
This might not always be desirable so this commit makes it configurable.
The use case where `canonicalize-path` comes in handy is the following:
You want to provide dotfiles in the Filesystem Hierarchy Standard under
`/usr/local/share/ypid_dotfiles/`. Now you want to provide
`.config/dotfiles` as a default in `/etc/skel`. When you now
pre-configure `/etc/skel` by running dotbot in it set has HOME, dotfiles
will refer to `/usr/local/share/ypid_dotfiles/` and not
`/etc/skel/.config/dotfiles` which does not look nice.
This is related to but not the same as the `relative` parameter used
with link commands.
This patch makes the tests (including the test driver) run entirely
inside Vagrant, which avoids calling the very slow `vagrant` driver many
times for running the tests. On my machine, `./test` runs in 22 seconds,
down from hundreds of seconds prior to this patch.
This also has the nice side effect of matching how the Travis CI tests
were run, so there's no need for a separate `test_travis` anymore.
Comparing strings and integers with `is` is a bug: comparisons should be
done with `==`. It might not have caused observable problems in the past
because small integers and strings can be interned.
Previously, clean read the defaults once, and then it updated the
setting for each entry it read. This resulted in the defaults being
clobbered and then not being respected for subsequent entries. This
patch fixes the issue by re-reading the defaults before processing each
item.
The other plugins (link, shell) do not have this problem.
This patch makes the launcher script prefer `python`, when present, over
`python3`. This way, the launcher uses the user's preferred `python`
(which is often set up as a symbolic link to a particular python2.x or
python3.x), when available.
