De-emphasise the package management aspects, since these days
almost everyone prefers to use modern package managers such as
rpm / dpkg / Nix for (system-wide) package management.
Also include more popular modern use cases for Stow such as management
of dotfiles and software compiled in the user's $HOME directory.
Fixes#22: https://github.com/aspiers/stow/issues/22
- The `sanitize_path_options` functions remove all trailing
and leading spaces. So any valid directory like ` 123`,
`123 ` can not be used
- Also if there are two directories ` 123` and `123`, and if
user pick the ` 123` as option to `-d` or `-t`, then stow pick
directory `123` as the argument instead of ` 123` as user want.
```
STOW_DIR=. stow -n -v3 -t \ 123 456
stow dir is /tmp/test
stow dir path relative to target 123 is ..
cwd now 123
cwd restored to /tmp/test
cwd now 123
Planning stow of package 456...
Stowing contents of ../456 (cwd=/tmp/test/123)
Planning stow of package 456... done
cwd restored to /tmp/test
WARNING: in simulation mode so not modifying filesystem.
```
- This commit remove the check in `sanitize_path_options` function,
and now stow can work with those directories. There have been a check
for valid directory, so we are safe.
Previously STOW_DIR=0 would cause the cwd to be used as the STOW_DIR.
Make that instead raise an error. Do similar validation on the target
directory.
Closes#7 - https://github.com/aspiers/stow/pull/7
In shell, a variable is often considered unset even if it is
set to the empty string. In other words,
STOW_DIR= stow [args]
is an idiomatic alternative to writing:
unset STOW_DIR
stow [args]
and it also has the advantage of temporarily "unsetting" STOW_DIR
for a single command.
Therefore we should treat STOW_DIR being set to the empty string
as equivalent to it not being set at all.
Thanks to Cuong Manh Le for highlighting this issue!
Fixes#6 - https://github.com/aspiers/stow/issues/6Closes#5 - https://github.com/aspiers/stow/pull/5
I'm guessing it was added due to a misunderstanding of how shell
quoting works. When you invoke
stow --ignore=".#.*" ...
the shell strips out the quotes before the Perl process ever sees them.
I can't imagine any sensible scenario in which you would need to invoke
stow --ignore='"foo"'
but if the user has a filename containing quotes at the beginning and
end, they can now choose to ignore it (prior to this patch, they couldn't).
