[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature Request: add wildcards and recursive to ln
From: |
Bob Proulx |
Subject: |
Re: Feature Request: add wildcards and recursive to ln |
Date: |
Wed, 20 Feb 2008 15:16:22 -0700 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Vincent J. Schiavoni wrote:
> Please consider adding features to ln to allow recursive linking of
> files in a directory and the use of wildcards to support that feature.
>
> At present, there appears to be no way to link large numbers of files in
> a "batch"-type mode - each file must be linked individually, or a
> work-around used such as for example "for i in /usr/local/lib/*; do ln
> -s $i /usr/lib/ ; done". It would be nice to have that functionality
> integrated into ln.
It seems to me that 'ln' already supports that feature.
I am not sure what you are attempting but let me take a "shot in the
dark" and think that perhaps you are managing a collection of files in
groups with symlinks and suggest that you look at GNU Stow. If this
is pertinent then great. If not then nothing lost by suggesting it.
Stow is a tool for managing the installation of multiple software
packages in the same run-time directory tree. One historical
difficulty of this task has been the need to administer, upgrade,
install, and remove files in independent packages without confusing
them with other files sharing the same filesystem space. For
instance, it is common to install Perl and Emacs in
`/usr/local'. When one does so, one winds up with the following
files(1) in `/usr/local/man/man1': `a2p.1'; `ctags.1'; `emacs.1';
`etags.1'; `h2ph.1'; `perl.1'; and `s2p.1'. Now suppose it's time to
uninstall Perl. Which man pages get removed? Obviously `perl.1' is
one of them, but it should not be the administrator's responsibility
to memorize the ownership of individual files by separate packages.
The approach used by Stow is to install each package into its own
tree, then use symbolic links to make it appear as though the files
are installed in the common tree. Administration can be performed in
the package's private tree in isolation from clutter from other
packages. Stow can then be used to update the symbolic links. The
structure of each private tree should reflect the desired structure in
the common tree; I.e. (in the typical case) there should be a `bin'
directory containing executables, a `man/man1' directory containing
section 1 man pages, and so on.
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').
For information about the latest version of Stow, you can refer to
http://www.gnu.org/software/stow/.
Bob