Why:
* We want to selectively apply expansion to:
* Only options from stowrc files.
* Only options that take a path.
* This requires ability to:
* Differentiate cli options from stowrc options
* Distinguish between individual stowrc options.
This change addresses the need by:
* Options from ARGV and stowrc files are separately parsed, resulting in
two options hashes.
* Creating an option hash from stowrc files allows modification of
specific arguments without having to rely on something like regex
parsing of the options.
* get_config_file_options modified to return options hash.
* Uses the same parse_options function that parses ARGV
* Add Hash:Merge to dependencies in order to merge the two option
hashes.
* process_options() merges the two option hashes.
* Get option hash for ARGV
* Get option hash from get_config_file_options().
* Merge the two hashes with Hash::Merge.
* Sanitation and checks are ran on the merged options.
* The options -S, -D, and -R are ignored in stowrc files.
* Due to the way argument parsing happens, the effect of these
actions is not carried from stowrc into parsing of cli options.
* It doesn't seem to make sense to put these options in stowrc
anyway.
Why:
* Want to be able to selectively apply filepath expansion to:
1. Only options in a stowrc file.
2. Only options that take a file path.
* Because of need 1, any expansion must be performed on stowrc options
before merging with cli options.
* Because of need 2, stowrc options need to be parsed before expansion
in order to know which options need expanding.
This change addresses the need by:
* Create parse_options()
* Implements option parsing logic previously in process_options()
* Takes an array as parameter instead of assuming ARGV
* Edit process_options() to still work as expected.
* Only change was to call parse_options() instead of directly
parsing ARGV
* By factoring out the option parsing code, we can reuse the existing
parsing code for stowrc options.
* Allows expansion of only the option itself, i.e expansion on
"$HOME/target" rather than "--target=$HOME/target"
* Allows easy determination of which options need expansion.
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).
