4d1167ffd7
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.
|
||
|---|---|---|
| automake | ||
| bin | ||
| doc | ||
| docker | ||
| lib | ||
| t | ||
| .gitignore | ||
| .travis.yml | ||
| aclocal.m4 | ||
| AUTHORS | ||
| build-docker.sh | ||
| Build.PL | ||
| configure.ac | ||
| COPYING | ||
| default-ignore-list | ||
| INSTALL.md | ||
| Makefile.am | ||
| MANIFEST | ||
| MANIFEST.SKIP | ||
| META.json | ||
| META.yml | ||
| NEWS | ||
| README.md | ||
| test-docker.sh | ||
| THANKS | ||
| TODO | ||
README for GNU Stow
This README describes GNU Stow. This is not the definitive documentation for Stow; for that, see the info manual.
Stow is a symlink farm manager program which takes distinct sets of software and/or data located in separate directories on the filesystem, and makes them all appear to be installed in a single directory tree.
Originally Stow was born to address the need to administer, upgrade,
install, and remove files in independent software packages without
confusing them with other files sharing the same file system space.
For instance, many years ago it used to be common to compile programs
such as Perl and Emacs from source and install them in /usr/local.
By using Stow, /usr/local/bin could contain symlinks to files within
/usr/local/stow/emacs/bin, /usr/local/stow/perl/bin etc., and
likewise recursively for any other subdirectories such as .../share,
.../man, and so on.
While this is useful for keeping track of system-wide and per-user
installations of software built from source, in more recent times
software packages are often managed by more sophisticated package
management software such as
rpm,
dpkg, and
Nix / GNU
Guix, or language-native
package managers such as Ruby's
gem, Python's
pip,
Javascript's npm,
and so on.
However Stow is still used not only for software package management, but also for other purposes, such as facilitating a more controlled approach to management of configuration files in the user's home directory, especially when coupled with version control systems.
Stow was inspired by Carnegie Mellon's Depot program, but is
substantially simpler and safer. Whereas Depot required database files
to keep things in sync, Stow stores no extra state between runs, so
there's no danger (as there was in Depot) of mangling directories when
file hierarchies don't match the database. Also unlike Depot, Stow will
never delete any files, directories, or links that appear in a Stow
directory (e.g., /usr/local/stow/emacs), so it's always possible
to rebuild the target tree (e.g., /usr/local).
Stow is implemented as a combination of a Perl script providing a CLI interface, and a backend Perl module which does most of the work.
You can get the latest information about Stow from the home page:
http://www.gnu.org/software/stow/
License
Stow is free software, licensed under the GNU General Public License,
which can be found in the file COPYING.
Installation
See INSTALL.md for installation instructions.
Feedback
Please do send comments, questions, and constructive criticism. The mailing lists and any other communication channels are detailed on the above home page.
Brief history
Stow was inspired by Carnegie Mellon's "Depot" program, but is
substantially simpler. Whereas Depot requires database files to keep
things in sync, Stow stores no extra state between runs, so there's no
danger (as there is in Depot) of mangling directories when file
hierarchies don't match the database. Also unlike Depot, Stow will
never delete any files, directories, or links that appear in a Stow
directory (e.g., /usr/local/stow/emacs), so it's always possible to
rebuild the target tree (e.g., /usr/local).