2011-11-24 11:28:09 -05:00
|
|
|
#!/usr/bin/perl
|
2019-06-27 09:02:19 -04:00
|
|
|
#
|
|
|
|
# This file is part of GNU Stow.
|
|
|
|
#
|
|
|
|
# GNU Stow is free software: you can redistribute it and/or modify it
|
|
|
|
# under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation, either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# GNU Stow is distributed in the hope that it will be useful, but
|
|
|
|
# WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
# General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see https://www.gnu.org/licenses/.
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
package Stow;
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
2016-11-21 09:56:26 -05:00
|
|
|
Stow - manage farms of symbolic links
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
|
|
|
my $stow = new Stow(%$options);
|
|
|
|
|
|
|
|
$stow->plan_unstow(@pkgs_to_unstow);
|
|
|
|
$stow->plan_stow (@pkgs_to_stow);
|
|
|
|
|
2011-11-24 17:49:22 -05:00
|
|
|
my %conflicts = $stow->get_conflicts;
|
|
|
|
$stow->process_tasks() unless %conflicts;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
This is the backend Perl module for GNU Stow, a program for managing
|
|
|
|
the installation of software packages, keeping them separate
|
|
|
|
(C</usr/local/stow/emacs> vs. C</usr/local/stow/perl>, for example)
|
|
|
|
while making them appear to be installed in the same place
|
|
|
|
(C</usr/local>).
|
|
|
|
|
|
|
|
Stow doesn't store an extra state between runs, so there's no danger
|
|
|
|
of mangling directories when file hierarchies don't match the
|
|
|
|
database. Also, stow will never delete any files, directories, or
|
|
|
|
links that appear in a stow directory, so it is always possible to
|
|
|
|
rebuild the target tree.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
|
|
|
|
2012-01-09 16:11:58 -05:00
|
|
|
use Carp qw(carp cluck croak confess longmess);
|
2012-01-09 16:25:35 -05:00
|
|
|
use File::Copy qw(move);
|
2011-11-24 11:28:09 -05:00
|
|
|
use File::Spec;
|
|
|
|
use POSIX qw(getcwd);
|
|
|
|
|
|
|
|
use Stow::Util qw(set_debug_level debug error set_test_mode
|
2024-04-07 12:19:37 -04:00
|
|
|
join_paths restore_cwd canon_path parent
|
|
|
|
adjust_dotfile unadjust_dotfile);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
our $ProgramName = 'stow';
|
|
|
|
our $VERSION = '@VERSION@';
|
|
|
|
|
2011-11-23 18:45:48 -05:00
|
|
|
our $LOCAL_IGNORE_FILE = '.stow-local-ignore';
|
|
|
|
our $GLOBAL_IGNORE_FILE = '.stow-global-ignore';
|
|
|
|
|
|
|
|
our @default_global_ignore_regexps =
|
|
|
|
__PACKAGE__->get_default_global_ignore_regexps();
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
# These are the default options for each Stow instance.
|
|
|
|
our %DEFAULT_OPTIONS = (
|
2012-02-18 15:13:32 -05:00
|
|
|
conflicts => 0,
|
|
|
|
simulate => 0,
|
|
|
|
verbose => 0,
|
|
|
|
paranoid => 0,
|
|
|
|
compat => 0,
|
|
|
|
test_mode => 0,
|
2016-07-31 16:55:55 -04:00
|
|
|
dotfiles => 0,
|
2012-02-18 15:13:32 -05:00
|
|
|
adopt => 0,
|
|
|
|
'no-folding' => 0,
|
|
|
|
ignore => [],
|
|
|
|
override => [],
|
|
|
|
defer => [],
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
|
|
|
|
=head1 CONSTRUCTORS
|
|
|
|
|
|
|
|
=head2 new(%options)
|
|
|
|
|
|
|
|
=head3 Required options
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item * dir - the stow directory
|
|
|
|
|
|
|
|
=item * target - the target directory
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=head3 Non-mandatory options
|
|
|
|
|
2012-02-18 09:08:17 -05:00
|
|
|
See the documentation for the F<stow> CLI front-end for information on these.
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item * conflicts
|
|
|
|
|
|
|
|
=item * simulate
|
|
|
|
|
|
|
|
=item * verbose
|
|
|
|
|
|
|
|
=item * paranoid
|
|
|
|
|
2012-02-18 09:08:17 -05:00
|
|
|
=item * compat
|
|
|
|
|
|
|
|
=item * test_mode
|
|
|
|
|
|
|
|
=item * adopt
|
|
|
|
|
2012-02-18 15:13:32 -05:00
|
|
|
=item * no-folding
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
=item * ignore
|
|
|
|
|
|
|
|
=item * override
|
|
|
|
|
|
|
|
=item * defer
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
N.B. This sets the current working directory to the target directory.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub new {
|
|
|
|
my $self = shift;
|
|
|
|
my $class = ref($self) || $self;
|
|
|
|
my %opts = @_;
|
|
|
|
|
|
|
|
my $new = bless { }, $class;
|
|
|
|
|
2011-11-24 17:49:22 -05:00
|
|
|
$new->{action_count} = 0;
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
for my $required_arg (qw(dir target)) {
|
|
|
|
croak "$class->new() called without '$required_arg' parameter\n"
|
|
|
|
unless exists $opts{$required_arg};
|
|
|
|
$new->{$required_arg} = delete $opts{$required_arg};
|
|
|
|
}
|
|
|
|
|
|
|
|
for my $opt (keys %DEFAULT_OPTIONS) {
|
|
|
|
$new->{$opt} = exists $opts{$opt} ? delete $opts{$opt}
|
|
|
|
: $DEFAULT_OPTIONS{$opt};
|
|
|
|
}
|
|
|
|
|
|
|
|
if (%opts) {
|
|
|
|
croak "$class->new() called with unrecognised parameter(s): ",
|
|
|
|
join(", ", keys %opts), "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
set_debug_level($new->get_verbosity());
|
|
|
|
set_test_mode($new->{test_mode});
|
|
|
|
$new->set_stow_dir();
|
|
|
|
$new->init_state();
|
|
|
|
|
|
|
|
return $new;
|
|
|
|
}
|
|
|
|
|
|
|
|
sub get_verbosity {
|
|
|
|
my $self = shift;
|
|
|
|
|
|
|
|
return $self->{verbose} unless $self->{test_mode};
|
|
|
|
|
2012-01-13 06:34:55 -05:00
|
|
|
return 0 unless exists $ENV{TEST_VERBOSE};
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0 unless length $ENV{TEST_VERBOSE};
|
|
|
|
|
|
|
|
# Convert TEST_VERBOSE=y into numeric value
|
|
|
|
$ENV{TEST_VERBOSE} = 3 if $ENV{TEST_VERBOSE} !~ /^\d+$/;
|
|
|
|
|
|
|
|
return $ENV{TEST_VERBOSE};
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 set_stow_dir([$dir])
|
|
|
|
|
|
|
|
Sets a new stow directory. This allows the use of multiple stow
|
|
|
|
directories within one Stow instance, e.g.
|
|
|
|
|
|
|
|
$stow->plan_stow('foo');
|
|
|
|
$stow->set_stow_dir('/different/stow/dir');
|
|
|
|
$stow->plan_stow('bar');
|
|
|
|
$stow->process_tasks;
|
|
|
|
|
|
|
|
If C<$dir> is omitted, uses the value of the C<dir> parameter passed
|
|
|
|
to the L<new()> constructor.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub set_stow_dir {
|
|
|
|
my $self = shift;
|
|
|
|
my ($dir) = @_;
|
|
|
|
if (defined $dir) {
|
|
|
|
$self->{dir} = $dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
my $stow_dir = canon_path($self->{dir});
|
2013-04-12 12:47:29 -04:00
|
|
|
my $target = canon_path($self->{target});
|
2024-03-09 13:11:00 -05:00
|
|
|
|
|
|
|
# Calculate relative path from target directory to stow directory.
|
|
|
|
# This will be commonly used as a prefix for constructing and
|
|
|
|
# recognising symlinks "installed" in the target directory which
|
|
|
|
# point to package files under the stow directory.
|
2013-04-12 12:47:29 -04:00
|
|
|
$self->{stow_path} = File::Spec->abs2rel($stow_dir, $target);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "stow dir is $stow_dir");
|
|
|
|
debug(2, 0, "stow dir path relative to target $target is $self->{stow_path}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
sub init_state {
|
|
|
|
my $self = shift;
|
|
|
|
|
|
|
|
# Store conflicts during pre-processing
|
2011-11-24 17:49:22 -05:00
|
|
|
$self->{conflicts} = {};
|
|
|
|
$self->{conflict_count} = 0;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
# Store command line packages to stow (-S and -R)
|
|
|
|
$self->{pkgs_to_stow} = [];
|
|
|
|
|
|
|
|
# Store command line packages to unstow (-D and -R)
|
|
|
|
$self->{pkgs_to_delete} = [];
|
|
|
|
|
|
|
|
# The following structures are used by the abstractions that allow us to
|
|
|
|
# defer operating on the filesystem until after all potential conflicts have
|
|
|
|
# been assessed.
|
|
|
|
|
|
|
|
# $self->{tasks}: list of operations to be performed (in order)
|
|
|
|
# each element is a hash ref of the form
|
|
|
|
# {
|
2012-01-09 16:25:35 -05:00
|
|
|
# action => ... ('create' or 'remove' or 'move')
|
|
|
|
# type => ... ('link' or 'dir' or 'file')
|
2011-11-24 11:28:09 -05:00
|
|
|
# path => ... (unique)
|
|
|
|
# source => ... (only for links)
|
2012-01-09 16:25:35 -05:00
|
|
|
# dest => ... (only for moving files)
|
2011-11-24 11:28:09 -05:00
|
|
|
# }
|
|
|
|
$self->{tasks} = [];
|
|
|
|
|
|
|
|
# $self->{dir_task_for}: map a path to the corresponding directory task reference
|
|
|
|
# This structure allows us to quickly determine if a path has an existing
|
|
|
|
# directory task associated with it.
|
|
|
|
$self->{dir_task_for} = {};
|
|
|
|
|
|
|
|
# $self->{link_task_for}: map a path to the corresponding directory task reference
|
|
|
|
# This structure allows us to quickly determine if a path has an existing
|
|
|
|
# directory task associated with it.
|
|
|
|
$self->{link_task_for} = {};
|
|
|
|
|
|
|
|
# N.B.: directory tasks and link tasks are NOT mutually exclusive due
|
|
|
|
# to tree splitting (which involves a remove link task followed by
|
|
|
|
# a create directory task).
|
|
|
|
}
|
|
|
|
|
|
|
|
=head1 METHODS
|
|
|
|
|
|
|
|
=head2 plan_unstow(@packages)
|
|
|
|
|
|
|
|
Plan which symlink/directory creation/removal tasks need to be executed
|
|
|
|
in order to unstow the given packages. Any potential conflicts are then
|
|
|
|
accessible via L<get_conflicts()>.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub plan_unstow {
|
|
|
|
my $self = shift;
|
|
|
|
my @packages = @_;
|
|
|
|
|
2020-11-11 13:19:43 -05:00
|
|
|
return unless @packages;
|
|
|
|
|
|
|
|
debug(2, 0, "Planning unstow of: @packages ...");
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
$self->within_target_do(sub {
|
|
|
|
for my $package (@packages) {
|
2024-03-03 19:53:51 -05:00
|
|
|
my $pkg_path = join_paths($self->{stow_path}, $package);
|
|
|
|
if (not -d $pkg_path) {
|
2012-02-18 15:12:14 -05:00
|
|
|
error("The stow directory $self->{stow_path} does not contain package $package");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "Planning unstow of package $package...");
|
2024-04-01 08:00:51 -04:00
|
|
|
$self->unstow_contents(
|
|
|
|
$package,
|
|
|
|
'.',
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
'.',
|
2024-04-01 08:00:51 -04:00
|
|
|
);
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "Planning unstow of package $package... done");
|
2011-11-24 17:49:22 -05:00
|
|
|
$self->{action_count}++;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 plan_stow(@packages)
|
|
|
|
|
|
|
|
Plan which symlink/directory creation/removal tasks need to be executed
|
|
|
|
in order to stow the given packages. Any potential conflicts are then
|
|
|
|
accessible via L<get_conflicts()>.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub plan_stow {
|
|
|
|
my $self = shift;
|
|
|
|
my @packages = @_;
|
|
|
|
|
2020-11-11 13:19:43 -05:00
|
|
|
return unless @packages;
|
|
|
|
|
|
|
|
debug(2, 0, "Planning stow of: @packages ...");
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
$self->within_target_do(sub {
|
|
|
|
for my $package (@packages) {
|
2024-03-03 19:53:51 -05:00
|
|
|
my $pkg_path = join_paths($self->{stow_path}, $package);
|
|
|
|
if (not -d $pkg_path) {
|
2012-02-18 15:12:14 -05:00
|
|
|
error("The stow directory $self->{stow_path} does not contain package $package");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "Planning stow of package $package...");
|
2011-11-24 11:28:09 -05:00
|
|
|
$self->stow_contents(
|
2011-11-23 18:45:48 -05:00
|
|
|
$self->{stow_path},
|
|
|
|
$package,
|
|
|
|
'.',
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
'.',
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "Planning stow of package $package... done");
|
2011-11-24 17:49:22 -05:00
|
|
|
$self->{action_count}++;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 within_target_do($code)
|
|
|
|
|
|
|
|
Execute code within target directory, preserving cwd.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $code
|
|
|
|
|
|
|
|
Anonymous subroutine to execute within target dir.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
This is done to ensure that the consumer of the Stow interface doesn't
|
|
|
|
have to worry about (a) what their cwd is, and (b) that their cwd
|
|
|
|
might change.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub within_target_do {
|
|
|
|
my $self = shift;
|
|
|
|
my ($code) = @_;
|
|
|
|
|
|
|
|
my $cwd = getcwd();
|
2011-11-23 19:45:29 -05:00
|
|
|
chdir($self->{target})
|
2012-07-08 20:06:13 -04:00
|
|
|
or error("Cannot chdir to target tree: $self->{target} ($!)");
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(3, 0, "cwd now $self->{target}");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
$self->$code();
|
|
|
|
|
|
|
|
restore_cwd($cwd);
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(3, 0, "cwd restored to $cwd");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=head2 stow_contents($stow_path, $package, $pkg_subdir, $target_subdir)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Stow the contents of the given directory.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $stow_path
|
|
|
|
|
|
|
|
Relative path from current (i.e. target) directory to the stow dir
|
|
|
|
containing the package to be stowed. This can differ from
|
|
|
|
C<$self->{stow_path}> when unfolding a (sub)tree which is already
|
|
|
|
stowed from a package in a different stow directory (see the "Multiple
|
|
|
|
Stow Directories" section of the manual).
|
|
|
|
|
|
|
|
=item $package
|
|
|
|
|
|
|
|
The package whose contents are being stowed.
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=item $pkg_subdir
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
Subdirectory of the installation image in the package directory which
|
|
|
|
needs stowing as a symlink which points to it. This is relative to
|
|
|
|
the top-level package directory.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=item $target_subdir
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
Subdirectory of the target directory which either needs a symlink to the
|
|
|
|
corresponding package subdirectory in the installation image, or if
|
|
|
|
it's an existing directory, it's an unfolded tree which may need to
|
|
|
|
be folded or recursed into.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
C<stow_node()> and C<stow_contents()> are mutually recursive.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub stow_contents {
|
|
|
|
my $self = shift;
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my ($stow_path, $package, $pkg_subdir, $target_subdir) = @_;
|
2024-03-31 18:41:02 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
return if $self->should_skip_target($pkg_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
my $cwd = getcwd();
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $msg = "Stowing contents of $stow_path / $package / $pkg_subdir (cwd=$cwd)";
|
2011-11-26 13:55:10 -05:00
|
|
|
$msg =~ s!$ENV{HOME}(/|$)!~$1!g;
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(3, 0, $msg);
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
debug(4, 1, "target subdir is $target_subdir");
|
|
|
|
|
|
|
|
# Calculate the path to the package directory or sub-directory
|
|
|
|
# whose contents need to be stowed, relative to the current
|
|
|
|
# (target directory). This is needed so that we can check it's a
|
|
|
|
# valid directory, and can read its contents to iterate over them.
|
|
|
|
my $pkg_path_from_cwd = join_paths($stow_path, $package, $pkg_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
error("stow_contents() called with non-directory target: $target_subdir")
|
|
|
|
unless $self->is_a_node($target_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
opendir my $DIR, $pkg_path_from_cwd
|
|
|
|
or error("cannot read directory: $pkg_path_from_cwd ($!)");
|
2011-11-24 11:28:09 -05:00
|
|
|
my @listing = readdir $DIR;
|
|
|
|
closedir $DIR;
|
|
|
|
|
|
|
|
NODE:
|
2024-04-06 08:33:53 -04:00
|
|
|
for my $node (sort @listing) {
|
2011-11-24 11:28:09 -05:00
|
|
|
next NODE if $node eq '.';
|
|
|
|
next NODE if $node eq '..';
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
|
|
|
|
my $package_node_path = join_paths($pkg_subdir, $node);
|
|
|
|
my $target_node = $node;
|
2016-07-31 16:55:55 -04:00
|
|
|
|
|
|
|
if ($self->{dotfiles}) {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $adjusted = adjust_dotfile($node);
|
|
|
|
if ($adjusted ne $node) {
|
|
|
|
debug(4, 1, "Adjusting: $node => $adjusted");
|
|
|
|
$target_node = $adjusted;
|
|
|
|
}
|
2016-07-31 16:55:55 -04:00
|
|
|
}
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $target_node_path = join_paths($target_subdir, $target_node);
|
|
|
|
|
|
|
|
next NODE if $self->ignore($stow_path, $package, $target_node_path);
|
2016-07-31 16:55:55 -04:00
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
$self->stow_node(
|
2011-11-23 18:45:48 -05:00
|
|
|
$stow_path,
|
|
|
|
$package,
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$package_node_path,
|
|
|
|
$target_node_path
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=head2 stow_node($stow_path, $package, $pkg_subpath, $target_subpath)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Stow the given node
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $stow_path
|
|
|
|
|
|
|
|
Relative path from current (i.e. target) directory to the stow dir
|
|
|
|
containing the node to be stowed. This can differ from
|
|
|
|
C<$self->{stow_path}> when unfolding a (sub)tree which is already
|
|
|
|
stowed from a package in a different stow directory (see the "Multiple
|
|
|
|
Stow Directories" section of the manual).
|
|
|
|
|
|
|
|
=item $package
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
The package containing the node being stowed.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=item $pkg_subpath
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
Subpath of the installation image in the package directory which needs
|
|
|
|
stowing as a symlink which points to it. This is relative to the
|
|
|
|
top-level package directory.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=item $target_subpath
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
Subpath of the target directory which either needs a symlink to the
|
|
|
|
corresponding package subpathectory in the installation image, or if
|
|
|
|
it's an existing directory, it's an unfolded tree which may need to
|
|
|
|
be folded or recursed into.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
2024-04-01 06:17:59 -04:00
|
|
|
C<stow_node()> and C<stow_contents()> are mutually recursive.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub stow_node {
|
|
|
|
my $self = shift;
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my ($stow_path, $package, $pkg_subpath, $target_subpath) = @_;
|
2011-11-23 18:45:48 -05:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
debug(3, 0, "Stowing entry $stow_path / $package / $pkg_subpath");
|
|
|
|
# Calculate the path to the package directory or sub-directory
|
|
|
|
# whose contents need to be stowed, relative to the current
|
|
|
|
# (target directory). This is needed so that we can check it's a
|
|
|
|
# valid directory, and can read its contents to iterate over them.
|
|
|
|
my $pkg_path_from_cwd = join_paths($stow_path, $package, $pkg_subpath);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Don't try to stow absolute symlinks (they can't be unstowed)
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
if (-l $pkg_path_from_cwd) {
|
|
|
|
my $link_dest = $self->read_a_link($pkg_path_from_cwd);
|
2024-04-01 16:21:06 -04:00
|
|
|
if ($link_dest =~ m{\A/}) {
|
2011-11-24 17:49:22 -05:00
|
|
|
$self->conflict(
|
|
|
|
'stow',
|
|
|
|
$package,
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
"source is an absolute symlink $pkg_path_from_cwd => $link_dest"
|
2011-11-24 17:49:22 -05:00
|
|
|
);
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(3, 0, "Absolute symlinks cannot be unstowed");
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
# How many directories deep are we?
|
|
|
|
my $level = ($pkg_subpath =~ tr,/,,);
|
|
|
|
debug(2, 1, "level of $pkg_subpath is $level");
|
|
|
|
|
|
|
|
# Calculate the destination of the symlink which would need to be
|
|
|
|
# installed within this directory in the absence of folding. This
|
|
|
|
# is relative to the target (sub-)directory where the symlink will
|
|
|
|
# be installed when the plans are executed, so as we descend down
|
|
|
|
# into the package hierarchy, it will have extra "../" segments
|
|
|
|
# prefixed to it.
|
|
|
|
my $link_dest = join_paths('../' x $level, $pkg_path_from_cwd);
|
|
|
|
debug(4, 1, "link destination $link_dest");
|
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Does the target already exist?
|
2024-04-01 06:17:59 -04:00
|
|
|
if ($self->is_a_link($target_subpath)) {
|
2011-11-21 18:21:48 -05:00
|
|
|
# Where is the link pointing?
|
2024-04-01 06:17:59 -04:00
|
|
|
my $existing_link_dest = $self->read_a_link($target_subpath);
|
2024-03-31 19:39:18 -04:00
|
|
|
if (not $existing_link_dest) {
|
2024-04-01 06:17:59 -04:00
|
|
|
error("Could not read link: $target_subpath");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 06:17:59 -04:00
|
|
|
debug(4, 1, "Evaluate existing link: $target_subpath => $existing_link_dest");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-25 10:23:08 -05:00
|
|
|
# Does it point to a node under any stow directory?
|
2024-04-01 16:57:36 -04:00
|
|
|
my ($existing_pkg_path_from_cwd, $existing_stow_path, $existing_package) =
|
2024-04-01 06:17:59 -04:00
|
|
|
$self->find_stowed_path($target_subpath, $existing_link_dest);
|
2024-04-01 16:57:36 -04:00
|
|
|
if (not $existing_pkg_path_from_cwd) {
|
2011-11-24 17:49:22 -05:00
|
|
|
$self->conflict(
|
|
|
|
'stow',
|
|
|
|
$package,
|
2024-04-01 06:17:59 -04:00
|
|
|
"existing target is not owned by stow: $target_subpath"
|
2011-11-24 17:49:22 -05:00
|
|
|
);
|
2024-04-01 16:48:33 -04:00
|
|
|
return;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-04-01 06:17:59 -04:00
|
|
|
# Does the existing $target_subpath actually point to anything?
|
2024-04-01 16:57:36 -04:00
|
|
|
if ($self->is_a_node($existing_pkg_path_from_cwd)) {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
if ($existing_link_dest eq $link_dest) {
|
|
|
|
debug(2, 0, "--- Skipping $target_subpath as it already points to $link_dest");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 06:17:59 -04:00
|
|
|
elsif ($self->defer($target_subpath)) {
|
|
|
|
debug(2, 0, "--- Deferring installation of: $target_subpath");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 06:17:59 -04:00
|
|
|
elsif ($self->override($target_subpath)) {
|
|
|
|
debug(2, 0, "--- Overriding installation of: $target_subpath");
|
|
|
|
$self->do_unlink($target_subpath);
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$self->do_link($link_dest, $target_subpath);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 06:17:59 -04:00
|
|
|
elsif ($self->is_a_dir(join_paths(parent($target_subpath), $existing_link_dest)) &&
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$self->is_a_dir(join_paths(parent($target_subpath), $link_dest)))
|
2024-03-31 19:35:35 -04:00
|
|
|
{
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# If the existing link points to a directory,
|
2011-11-24 11:28:09 -05:00
|
|
|
# and the proposed new link points to a directory,
|
|
|
|
# then we can unfold (split open) the tree at that point
|
|
|
|
|
2024-04-01 06:17:59 -04:00
|
|
|
debug(2, 0, "--- Unfolding $target_subpath which was already owned by $existing_package");
|
|
|
|
$self->do_unlink($target_subpath);
|
|
|
|
$self->do_mkdir($target_subpath);
|
2011-11-23 18:45:48 -05:00
|
|
|
$self->stow_contents(
|
|
|
|
$existing_stow_path,
|
|
|
|
$existing_package,
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$pkg_subpath,
|
2024-04-01 06:17:59 -04:00
|
|
|
$target_subpath,
|
2011-11-23 18:45:48 -05:00
|
|
|
);
|
|
|
|
$self->stow_contents(
|
|
|
|
$self->{stow_path},
|
|
|
|
$package,
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$pkg_subpath,
|
2024-04-01 06:17:59 -04:00
|
|
|
$target_subpath,
|
2011-11-23 18:45:48 -05:00
|
|
|
);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
$self->conflict(
|
2011-11-24 17:49:22 -05:00
|
|
|
'stow',
|
|
|
|
$package,
|
|
|
|
"existing target is stowed to a different package: "
|
2024-04-01 06:17:59 -04:00
|
|
|
. "$target_subpath => $existing_link_dest"
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
2011-11-21 18:21:48 -05:00
|
|
|
# The existing link is invalid, so replace it with a good link
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
debug(2, 0, "--- replacing invalid link: $target_subpath");
|
2024-04-01 06:17:59 -04:00
|
|
|
$self->do_unlink($target_subpath);
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$self->do_link($link_dest, $target_subpath);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
2024-04-01 06:17:59 -04:00
|
|
|
elsif ($self->is_a_node($target_subpath)) {
|
|
|
|
debug(4, 1, "Evaluate existing node: $target_subpath");
|
|
|
|
if ($self->is_a_dir($target_subpath)) {
|
2024-04-01 19:06:38 -04:00
|
|
|
if (! -d $pkg_path_from_cwd) {
|
|
|
|
# FIXME: why wasn't this ever needed before?
|
|
|
|
$self->conflict(
|
|
|
|
'stow',
|
|
|
|
$package,
|
|
|
|
"cannot stow non-directory $pkg_path_from_cwd over existing directory target $target_subpath"
|
|
|
|
);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
$self->stow_contents(
|
|
|
|
$self->{stow_path},
|
|
|
|
$package,
|
|
|
|
$pkg_subpath,
|
|
|
|
$target_subpath,
|
|
|
|
);
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
2024-04-01 19:06:38 -04:00
|
|
|
# If we're here, $target_subpath is not a current or
|
|
|
|
# planned directory.
|
|
|
|
|
2012-01-09 16:25:35 -05:00
|
|
|
if ($self->{adopt}) {
|
2024-04-01 19:06:38 -04:00
|
|
|
if (-d $pkg_path_from_cwd) {
|
|
|
|
$self->conflict(
|
|
|
|
'stow',
|
|
|
|
$package,
|
|
|
|
"cannot stow directory $pkg_path_from_cwd over existing non-directory target $target_subpath"
|
|
|
|
);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
$self->do_mv($target_subpath, $pkg_path_from_cwd);
|
|
|
|
$self->do_link($link_dest, $target_subpath);
|
|
|
|
}
|
2012-01-09 16:25:35 -05:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
$self->conflict(
|
|
|
|
'stow',
|
|
|
|
$package,
|
2024-04-01 19:06:38 -04:00
|
|
|
"cannot stow $pkg_path_from_cwd over existing target $target_subpath since neither a link nor a directory and --adopt not specified"
|
2012-01-09 16:25:35 -05:00
|
|
|
);
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
elsif ($self->{'no-folding'} && -d $pkg_path_from_cwd && ! -l $pkg_path_from_cwd) {
|
2024-04-01 06:17:59 -04:00
|
|
|
$self->do_mkdir($target_subpath);
|
2012-02-18 15:13:32 -05:00
|
|
|
$self->stow_contents(
|
|
|
|
$self->{stow_path},
|
|
|
|
$package,
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$pkg_subpath,
|
2024-04-01 06:17:59 -04:00
|
|
|
$target_subpath,
|
2012-02-18 15:13:32 -05:00
|
|
|
);
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
else {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$self->do_link($link_dest, $target_subpath);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
=head2 should_skip_target($target_subdir)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
Determine whether C<$target_subdir> is a stow directory which should
|
|
|
|
not be stowed to or unstowed from. This mechanism protects stow
|
|
|
|
directories from being altered by stow, and is a necessary safety
|
|
|
|
check because the stow directory could live beneath the target
|
|
|
|
directory.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
=item $target_subdir => relative path to symlink target from the current directory
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns true iff target is a stow directory
|
|
|
|
|
|
|
|
cwd must be the top-level target directory, otherwise
|
|
|
|
C<marked_stow_dir()> won't work.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2024-03-30 10:03:56 -04:00
|
|
|
sub should_skip_target {
|
2011-11-24 11:28:09 -05:00
|
|
|
my $self = shift;
|
|
|
|
my ($target) = @_;
|
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Don't try to remove anything under a stow directory
|
2011-11-24 11:28:09 -05:00
|
|
|
if ($target eq $self->{stow_path}) {
|
2014-09-21 19:36:25 -04:00
|
|
|
warn "WARNING: skipping target which was current stow directory $target\n";
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-11-22 10:50:12 -05:00
|
|
|
if ($self->marked_stow_dir($target)) {
|
2024-03-30 10:03:56 -04:00
|
|
|
warn "WARNING: skipping marked Stow directory $target\n";
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (-e join_paths($target, ".nonstow")) {
|
2014-09-21 19:36:25 -04:00
|
|
|
warn "WARNING: skipping protected directory $target\n";
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2024-03-30 10:03:56 -04:00
|
|
|
debug(4, 1, "$target not protected; shouldn't skip");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-03-30 10:03:56 -04:00
|
|
|
# cwd must be the top-level target directory, otherwise
|
|
|
|
# marked_stow_dir() won't work.
|
2011-11-22 10:50:12 -05:00
|
|
|
sub marked_stow_dir {
|
2011-11-24 11:28:09 -05:00
|
|
|
my $self = shift;
|
2024-04-01 10:58:09 -04:00
|
|
|
my ($dir) = @_;
|
|
|
|
if (-e join_paths($dir, ".stow")) {
|
|
|
|
debug(5, 5, "> $dir contained .stow");
|
2024-03-30 10:03:56 -04:00
|
|
|
return 1;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=head2 unstow_contents($package, $pkg_subdir, $target_subdir)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Unstow the contents of the given directory
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $package
|
|
|
|
|
|
|
|
The package whose contents are being unstowed.
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=item $pkg_subdir
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
Subdirectory of the installation image in the package directory which
|
|
|
|
may need a symlink pointing to it to be unstowed. This is relative to
|
|
|
|
the top-level package directory.
|
|
|
|
|
|
|
|
=item $target_subdir
|
|
|
|
|
|
|
|
Subdirectory of the target directory which either needs unstowing of a
|
|
|
|
symlink to the corresponding package subdirectory in the installation
|
|
|
|
image, or if it's an existing directory, it's an unfolded tree which
|
|
|
|
may need to be recursed into.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
C<unstow_node()> and C<unstow_contents()> are mutually recursive.
|
2024-04-01 16:23:35 -04:00
|
|
|
Here we traverse the package tree, rather than the target tree.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub unstow_contents {
|
|
|
|
my $self = shift;
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my ($package, $pkg_subdir, $target_subdir) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
return if $self->should_skip_target($target_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
my $cwd = getcwd();
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $msg = "Unstowing contents of $self->{stow_path} / $package / $pkg_subdir (cwd=$cwd" . ($self->{compat} ? ', compat' : '') . ")";
|
2011-11-24 11:28:09 -05:00
|
|
|
$msg =~ s!$ENV{HOME}/!~/!g;
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(3, 0, $msg);
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
debug(4, 1, "target subdir is $target_subdir");
|
|
|
|
|
|
|
|
# Calculate the path to the package directory or sub-directory
|
|
|
|
# whose contents need to be unstowed, relative to the current
|
|
|
|
# (target directory). This is needed so that we can check it's a
|
|
|
|
# valid directory, and can read its contents to iterate over them.
|
|
|
|
my $pkg_path_from_cwd = join_paths($self->{stow_path}, $package, $pkg_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 08:00:51 -04:00
|
|
|
if ($self->{compat}) {
|
|
|
|
# In compat mode we traverse the target tree not the source tree,
|
|
|
|
# so we're unstowing the contents of /target/foo, there's no
|
|
|
|
# guarantee that the corresponding /stow/mypkg/foo exists.
|
2024-04-01 10:15:58 -04:00
|
|
|
error("unstow_contents() in compat mode called with non-directory target: $target_subdir")
|
|
|
|
unless -d $target_subdir;
|
2024-04-01 08:00:51 -04:00
|
|
|
}
|
|
|
|
else {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
# We traverse the package installation image tree not the
|
|
|
|
# target tree, so $pkg_path_from_cwd must exist.
|
|
|
|
error("unstow_contents() called with non-directory path: $pkg_path_from_cwd")
|
|
|
|
unless -d $pkg_path_from_cwd;
|
2024-04-01 08:00:51 -04:00
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
# When called at the top level, $target_subdir should exist. And
|
2024-04-01 08:00:51 -04:00
|
|
|
# unstow_node() should only call this via mutual recursion if
|
2024-04-01 10:15:58 -04:00
|
|
|
# $target_subdir exists.
|
|
|
|
error("unstow_contents() called with invalid target: $target_subdir")
|
|
|
|
unless $self->is_a_node($target_subdir);
|
2024-04-01 08:00:51 -04:00
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $dir = $self->{compat} ? $target_subdir : $pkg_path_from_cwd;
|
2024-04-01 08:00:51 -04:00
|
|
|
opendir my $DIR, $dir
|
|
|
|
or error("cannot read directory: $dir ($!)");
|
2011-11-24 11:28:09 -05:00
|
|
|
my @listing = readdir $DIR;
|
|
|
|
closedir $DIR;
|
|
|
|
|
|
|
|
NODE:
|
2024-04-06 08:33:53 -04:00
|
|
|
for my $node (sort @listing) {
|
2011-11-24 11:28:09 -05:00
|
|
|
next NODE if $node eq '.';
|
|
|
|
next NODE if $node eq '..';
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
|
|
|
|
my $package_node = $node;
|
|
|
|
my $target_node = $node;
|
2016-07-31 16:55:55 -04:00
|
|
|
|
|
|
|
if ($self->{dotfiles}) {
|
2024-04-07 12:19:37 -04:00
|
|
|
if ($self->{compat}) {
|
|
|
|
# $node is in the target tree, so we need to reverse
|
|
|
|
# adjust any .* files in case they came from a dot-*
|
|
|
|
# file.
|
|
|
|
my $adjusted = unadjust_dotfile($node);
|
|
|
|
if ($adjusted ne $node) {
|
|
|
|
debug(4, 1, "Reverse adjusting: $node => $adjusted");
|
|
|
|
$package_node = $adjusted;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
# $node is in the package tree, so adjust any dot-*
|
|
|
|
# files for the target.
|
|
|
|
my $adjusted = adjust_dotfile($node);
|
|
|
|
if ($adjusted ne $node) {
|
|
|
|
debug(4, 1, "Adjusting: $node => $adjusted");
|
|
|
|
$target_node = $adjusted;
|
|
|
|
}
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
}
|
2016-07-31 16:55:55 -04:00
|
|
|
}
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $package_node_path = join_paths($pkg_subdir, $package_node);
|
|
|
|
my $target_node_path = join_paths($target_subdir, $target_node);
|
2016-07-31 16:55:55 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
next NODE if $self->ignore($self->{stow_path}, $package, $target_node_path);
|
|
|
|
|
|
|
|
$self->unstow_node(
|
|
|
|
$package,
|
|
|
|
$package_node_path,
|
|
|
|
$target_node_path
|
|
|
|
);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 08:00:51 -04:00
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
if (! $self->{compat} && -d $target_subdir) {
|
|
|
|
$self->cleanup_invalid_links($target_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=head2 unstow_node($package, $pkg_subpath, $target_subpath)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Unstow the given node.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $package
|
|
|
|
|
|
|
|
The package containing the node being unstowed.
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
=item $pkg_subpath
|
|
|
|
|
|
|
|
Subpath of the installation image in the package directory which needs
|
|
|
|
stowing as a symlink which points to it. This is relative to the
|
|
|
|
top-level package directory.
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
=item $target_subpath
|
2024-03-31 11:10:08 -04:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
Subpath of the target directory which either needs a symlink to the
|
|
|
|
corresponding package subpathectory in the installation image, or if
|
|
|
|
it's an existing directory, it's an unfolded tree which may need to
|
|
|
|
be folded or recursed into.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
C<unstow_node()> and C<unstow_contents()> are mutually recursive.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub unstow_node {
|
|
|
|
my $self = shift;
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my ($package, $pkg_subpath, $target_subpath) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
debug(3, 0, "Unstowing entry from target: $target_subpath");
|
|
|
|
debug(4, 1, "Package entry: $self->{stow_path} / $package / $pkg_subpath");
|
|
|
|
# Calculate the path to the package directory or sub-directory
|
|
|
|
# whose contents need to be unstowed, relative to the current
|
|
|
|
# (target directory).
|
2011-11-21 18:21:48 -05:00
|
|
|
# Does the target exist?
|
2024-04-01 10:15:58 -04:00
|
|
|
if ($self->is_a_link($target_subpath)) {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$self->unstow_link_node($package, $pkg_subpath, $target_subpath);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 19:36:51 -04:00
|
|
|
elsif (-d $target_subpath) {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
$self->unstow_contents($package, $pkg_subpath, $target_subpath);
|
2024-04-01 08:00:51 -04:00
|
|
|
|
|
|
|
# This action may have made the parent directory foldable
|
2024-04-01 17:29:03 -04:00
|
|
|
if (my $parent_in_pkg = $self->foldable($target_subpath)) {
|
|
|
|
$self->fold_tree($target_subpath, $parent_in_pkg);
|
2024-04-01 08:00:51 -04:00
|
|
|
}
|
|
|
|
}
|
2024-04-01 10:15:58 -04:00
|
|
|
elsif (-e $target_subpath) {
|
2024-04-01 19:36:51 -04:00
|
|
|
debug(2, 1, "$target_subpath doesn't need to be unstowed");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
2024-04-01 10:15:58 -04:00
|
|
|
debug(2, 1, "$target_subpath did not exist to be unstowed");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 06:46:10 -04:00
|
|
|
sub unstow_link_node {
|
|
|
|
my $self = shift;
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my ($package, $pkg_subpath, $target_subpath) = @_;
|
2024-04-01 10:15:58 -04:00
|
|
|
debug(4, 2, "Evaluate existing link: $target_subpath");
|
2024-04-01 06:46:10 -04:00
|
|
|
|
|
|
|
# Where is the link pointing?
|
2024-04-01 16:26:21 -04:00
|
|
|
my $link_dest = $self->read_a_link($target_subpath);
|
|
|
|
if (not $link_dest) {
|
2024-04-01 10:15:58 -04:00
|
|
|
error("Could not read link: $target_subpath");
|
2024-04-01 06:46:10 -04:00
|
|
|
}
|
|
|
|
|
2024-04-01 16:26:21 -04:00
|
|
|
if ($link_dest =~ m{\A/}) {
|
|
|
|
warn "Ignoring an absolute symlink: $target_subpath => $link_dest\n";
|
2024-04-01 16:48:33 -04:00
|
|
|
return;
|
2024-04-01 06:46:10 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
# Does it point to a node under any stow directory?
|
2024-04-01 16:55:51 -04:00
|
|
|
my ($existing_pkg_path_from_cwd, $existing_stow_path, $existing_package) =
|
2024-04-01 16:26:21 -04:00
|
|
|
$self->find_stowed_path($target_subpath, $link_dest);
|
2024-04-01 16:55:51 -04:00
|
|
|
if (not $existing_pkg_path_from_cwd) {
|
2024-04-07 08:08:56 -04:00
|
|
|
# The user is unstowing the package, so they don't want links to it.
|
|
|
|
# Therefore we should allow them to have a link pointing elsewhere
|
|
|
|
# which would conflict with the package if they were stowing it.
|
|
|
|
debug(5, 3, "Ignoring unowned link $target_subpath => $link_dest");
|
2024-04-01 07:12:27 -04:00
|
|
|
return;
|
2024-04-01 06:46:10 -04:00
|
|
|
}
|
|
|
|
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
my $pkg_path_from_cwd = join_paths($self->{stow_path}, $package, $pkg_subpath);
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
# Does the existing $target_subpath actually point to anything?
|
2024-04-01 16:55:51 -04:00
|
|
|
if (-e $existing_pkg_path_from_cwd) {
|
2024-04-01 19:36:51 -04:00
|
|
|
if ($existing_pkg_path_from_cwd eq $pkg_path_from_cwd) {
|
dotfiles: switch {un,}stow_{contents,node}() recursion parameters
Stow walks the package and target tree hierarchies by using mutually
recursive pairs of functions:
- `stow_contents()` and `stow_node()`
- `unstow_contents()` and `unstow_node()`
As Stow runs its planning from the target directory (`plan_*()` both
call `within_target_do()`), previously the parameters for these
included:
- `$target_subpath` (or `$target_subdir` in the `*_node()` functions):
the relative path from the target top-level directory to the target
subdirectory (initially `.` at the beginning of recursion). For
example, this could be `dir1/subdir1/file1`.
- `$source`: the relative path from the target _subdirectory_ (N.B. _not_
top-level directory) to the package subdirectory. For example, if
the relative path to the Stow directory is `../stow`, this could be
`../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing
to construct a new link, or when unstowing to detect whether the
link can be unstowed.
Each time it descends into a further subdirectory of the target and
package, it appends the new path segment onto both of these, and also
prefixes `$source` with another `..`. When the `--dotfiles` parameter
is enabled, it adjusts `$target_subdir`, performing the `dot-foo` =>
`.foo` adjustment on all segments of the path in one go. In this
case, `$target_subpath` could be something like `.dir1/subdir1/file1`,
and the corresponding `$source` could be something like
`../../../stow/pkg1/dot-dir1/subdir1/file1`.
However this doesn't leave an easy way to obtain the relative path
from the target _top-level_ directory to the package subdirectory
(i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for
checking its existence and if necessary iterating over its contents.
The current implementation solves this by including an extra `$level`
parameter which tracks the recursion depth, and uses that to strip the
right number of leading path segments off the front of `$source`.
(In the above example, it would remove `../..`.)
This implementation isn't the most elegant because:
- It involves adding things to `$source` and then removing them again.
- It performs the `dot-` => `.` adjustment on every path segment
at each level, which is overkill, since when recursing down a level,
only adjustment on the final subdirectory is required since the higher
segments have already had any required adjustment.
This in turn requires `adjust_dotfile` to be more complex than it
needs to be.
It also prevents a potential future where we might want Stow to
optionally start iterating from within a subdirectory of the whole
package install image / target tree, avoiding adjustment at higher
levels and only doing it at the levels below the starting point.
- It requires passing an extra `$level` parameter which can be
automatically calculated simply by counting the number of slashes
in `$target_subpath`.
So change the `$source` recursion parameter to instead track the
relative path from the top-level package directory to the package
subdirectory or file being considered for (un)stowing, and rename it
to avoid the ambiguity caused by the word "source".
Also automatically calculate the depth simply by counting the number
of slashes, and reconstruct `$source` when needed by combining the
relative path to the Stow directory with the package name and
`$target_subpath`.
Closes #33.
2024-04-01 17:50:58 -04:00
|
|
|
# It points to the package we're unstowing, so unstow the link.
|
2024-04-01 19:36:51 -04:00
|
|
|
$self->do_unlink($target_subpath);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
debug(5, 3, "Ignoring link $target_subpath => $link_dest");
|
|
|
|
}
|
2024-04-01 06:46:10 -04:00
|
|
|
}
|
|
|
|
else {
|
2024-04-01 11:06:12 -04:00
|
|
|
debug(2, 0, "--- removing invalid link into a stow directory: $pkg_path_from_cwd");
|
2024-04-01 10:15:58 -04:00
|
|
|
$self->do_unlink($target_subpath);
|
2024-04-01 06:46:10 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 16:51:24 -04:00
|
|
|
=head2 link_owned_by_package($target_subpath, $link_dest)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine whether the given link points to a member of a stowed
|
|
|
|
package.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
=item $target_subpath
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Path to a symbolic link under current directory.
|
|
|
|
|
2024-04-01 16:51:24 -04:00
|
|
|
=item $link_dest
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Where that link points to.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Lossy wrapper around find_stowed_path().
|
|
|
|
|
|
|
|
Returns the package iff link is owned by stow, otherwise ''.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2020-11-01 19:52:41 -05:00
|
|
|
sub link_owned_by_package {
|
2011-11-23 18:45:48 -05:00
|
|
|
my $self = shift;
|
2024-04-01 16:51:24 -04:00
|
|
|
my ($target_subpath, $link_dest) = @_;
|
2011-11-23 18:45:48 -05:00
|
|
|
|
2024-04-01 11:06:12 -04:00
|
|
|
my ($pkg_path_from_cwd, $stow_path, $package) =
|
2024-04-01 16:51:24 -04:00
|
|
|
$self->find_stowed_path($target_subpath, $link_dest);
|
2011-11-23 18:45:48 -05:00
|
|
|
return $package;
|
|
|
|
}
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
=head2 find_stowed_path($target_subpath, $link_dest)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine whether the given symlink within the target directory is a
|
|
|
|
stowed path pointing to a member of a package under the stow dir, and
|
|
|
|
if so, obtain a breakdown of information about this stowed path.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
=item $target_subpath
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Path to a symbolic link somewhere under the target directory, relative
|
|
|
|
to the top-level target directory (which is also expected to be the
|
|
|
|
current directory).
|
|
|
|
|
|
|
|
=item $link_dest
|
|
|
|
|
|
|
|
Where that link points to (needed because link might not exist yet due
|
|
|
|
to two-phase approach, so we can't just call C<readlink()>). If this
|
|
|
|
is owned by Stow, it will be expressed relative to (the directory
|
2024-04-01 10:15:58 -04:00
|
|
|
containing) C<$target_subpath>. However if it's not, it could of course be
|
2024-03-31 11:10:08 -04:00
|
|
|
relative or absolute, point absolutely anywhere, and could even be
|
|
|
|
dangling.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
2024-04-01 11:18:52 -04:00
|
|
|
Returns C<($pkg_path_from_cwd, $stow_path, $package)> where
|
|
|
|
C<$pkg_path_from_cwd> and C<$stow_path> are relative from the
|
|
|
|
top-level target directory. C<$pkg_path_from_cwd> is the full
|
|
|
|
relative path to the member of the package pointed to by
|
|
|
|
C<$link_dest>; C<$stow_path> is the relative path to the stow
|
|
|
|
directory; and C<$package> is the name of the package; or C<('', '',
|
|
|
|
'')> if link is not owned by stow.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
cwd must be the top-level target directory, otherwise
|
|
|
|
C<find_containing_marked_stow_dir()> won't work. Allow for stow dir
|
|
|
|
not being under target dir.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub find_stowed_path {
|
|
|
|
my $self = shift;
|
2024-04-01 10:15:58 -04:00
|
|
|
my ($target_subpath, $link_dest) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-03-31 10:38:38 -04:00
|
|
|
if (substr($link_dest, 0, 1) eq '/') {
|
2020-11-11 14:43:25 -05:00
|
|
|
# Symlink points to an absolute path, therefore it cannot be
|
|
|
|
# owned by Stow.
|
|
|
|
return ('', '', '');
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2020-11-11 14:43:25 -05:00
|
|
|
# Evaluate softlink relative to its target, without relying on
|
|
|
|
# what's actually on the filesystem, since the link might not
|
|
|
|
# exist yet.
|
2024-04-01 10:15:58 -04:00
|
|
|
debug(4, 2, "find_stowed_path(target=$target_subpath; source=$link_dest)");
|
2024-04-01 11:18:52 -04:00
|
|
|
my $pkg_path_from_cwd = join_paths(parent($target_subpath), $link_dest);
|
|
|
|
debug(4, 3, "is symlink destination $pkg_path_from_cwd owned by stow?");
|
2020-11-11 14:43:25 -05:00
|
|
|
|
|
|
|
# First check whether the link is owned by the current stow
|
2024-04-01 11:18:52 -04:00
|
|
|
# directory, in which case $pkg_path_from_cwd will be a prefix of
|
2020-11-11 14:43:25 -05:00
|
|
|
# $self->{stow_path}.
|
2024-04-01 11:18:52 -04:00
|
|
|
my ($package, $pkg_subpath) = $self->link_dest_within_stow_dir($pkg_path_from_cwd);
|
2020-11-11 14:43:25 -05:00
|
|
|
if (length $package) {
|
2024-04-01 11:18:52 -04:00
|
|
|
debug(4, 3, "yes - package $package in $self->{stow_path} may contain $pkg_subpath");
|
|
|
|
return ($pkg_path_from_cwd, $self->{stow_path}, $package);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2011-11-23 18:45:48 -05:00
|
|
|
# If no .stow file was found, we need to find out whether it's
|
2024-04-01 11:18:52 -04:00
|
|
|
# owned by the current stow directory, in which case
|
|
|
|
# $pkg_path_from_cwd will be a prefix of $self->{stow_path}.
|
|
|
|
my ($stow_path, $ext_package) = $self->find_containing_marked_stow_dir($pkg_path_from_cwd);
|
2020-11-11 14:43:25 -05:00
|
|
|
if (length $stow_path) {
|
2024-04-01 11:18:52 -04:00
|
|
|
debug(5, 5, "yes - $stow_path in $pkg_path_from_cwd was marked as a stow dir; package=$ext_package");
|
|
|
|
return ($pkg_path_from_cwd, $stow_path, $ext_package);
|
2019-06-28 10:22:44 -04:00
|
|
|
}
|
|
|
|
|
2020-11-11 14:43:25 -05:00
|
|
|
return ('', '', '');
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 link_dest_within_stow_dir($link_dest)
|
|
|
|
|
|
|
|
Detect whether symlink destination is within current stow dir
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $link_dest - destination of the symlink relative
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
2024-04-01 11:08:56 -04:00
|
|
|
Returns C<($package, $pkg_subpath)> - package within the current stow
|
|
|
|
dir and subpath within that package which the symlink points to.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2020-11-11 14:43:25 -05:00
|
|
|
sub link_dest_within_stow_dir {
|
|
|
|
my $self = shift;
|
2024-03-31 10:38:38 -04:00
|
|
|
my ($link_dest) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-03-31 10:38:38 -04:00
|
|
|
debug(4, 4, "common prefix? link_dest=$link_dest; stow_path=$self->{stow_path}");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-03-31 10:38:38 -04:00
|
|
|
my $removed = $link_dest =~ s,^\Q$self->{stow_path}/,,;
|
2020-11-11 14:43:25 -05:00
|
|
|
if (! $removed) {
|
2024-03-31 10:38:38 -04:00
|
|
|
debug(4, 3, "no - $link_dest not under $self->{stow_path}");
|
2020-11-11 14:43:25 -05:00
|
|
|
return ('', '');
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-03-31 10:38:38 -04:00
|
|
|
debug(4, 4, "remaining after removing $self->{stow_path}: $link_dest");
|
|
|
|
my @dirs = File::Spec->splitdir($link_dest);
|
2020-11-11 14:43:25 -05:00
|
|
|
my $package = shift @dirs;
|
2024-04-01 11:08:56 -04:00
|
|
|
my $pkg_subpath = File::Spec->catdir(@dirs);
|
|
|
|
return ($package, $pkg_subpath);
|
2020-11-11 14:43:25 -05:00
|
|
|
}
|
2019-06-28 10:22:29 -04:00
|
|
|
|
2024-04-01 11:07:09 -04:00
|
|
|
=head2 find_containing_marked_stow_dir($pkg_path_from_cwd)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Detect whether path is within a marked stow directory
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 11:07:09 -04:00
|
|
|
=item $pkg_path_from_cwd => path to directory to check
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns C<($stow_path, $package)> where C<$stow_path> is the highest
|
|
|
|
directory (relative from the top-level target directory) which is
|
|
|
|
marked as a Stow directory, and C<$package> is the containing package;
|
|
|
|
or C<('', '')> if no containing directory is marked as a stow
|
|
|
|
directory.
|
|
|
|
|
|
|
|
cwd must be the top-level target directory, otherwise
|
|
|
|
C<marked_stow_dir()> won't work.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2020-11-11 14:43:25 -05:00
|
|
|
sub find_containing_marked_stow_dir {
|
|
|
|
my $self = shift;
|
2024-04-01 11:07:09 -04:00
|
|
|
my ($pkg_path_from_cwd) = @_;
|
2020-11-11 14:43:25 -05:00
|
|
|
|
|
|
|
# Search for .stow files - this allows us to detect links
|
|
|
|
# owned by stow directories other than the current one.
|
2024-04-01 11:07:09 -04:00
|
|
|
my @segments = File::Spec->splitdir($pkg_path_from_cwd);
|
2020-11-11 14:43:25 -05:00
|
|
|
for my $last_segment (0 .. $#segments) {
|
2024-04-01 11:07:09 -04:00
|
|
|
my $pkg_path_from_cwd = join_paths(@segments[0 .. $last_segment]);
|
|
|
|
debug(5, 5, "is $pkg_path_from_cwd marked stow dir?");
|
|
|
|
if ($self->marked_stow_dir($pkg_path_from_cwd)) {
|
2020-11-11 14:43:25 -05:00
|
|
|
if ($last_segment == $#segments) {
|
|
|
|
# This should probably never happen. Even if it did,
|
|
|
|
# there would be no way of calculating $package.
|
|
|
|
internal_error("find_stowed_path() called directly on stow dir");
|
|
|
|
}
|
|
|
|
|
|
|
|
my $package = $segments[$last_segment + 1];
|
2024-04-01 11:07:09 -04:00
|
|
|
return ($pkg_path_from_cwd, $package);
|
2020-11-11 14:43:25 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return ('', '');
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 cleanup_invalid_links($dir)
|
|
|
|
|
|
|
|
Clean up orphaned links that may block folding
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $dir
|
|
|
|
|
|
|
|
Path to directory to check
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
This is invoked by C<unstow_contents()>. We only clean up links which
|
|
|
|
are both orphaned and owned by Stow, i.e. they point to a non-existent
|
|
|
|
location within a Stow package. These can block tree folding, and
|
|
|
|
they can easily occur when a file in Stow package is renamed or
|
|
|
|
removed, so the benefit should outweigh the low risk of actually
|
|
|
|
someone wanting to keep an orphaned link to within a Stow package.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub cleanup_invalid_links {
|
|
|
|
my $self = shift;
|
|
|
|
my ($dir) = @_;
|
|
|
|
|
2020-11-01 19:54:15 -05:00
|
|
|
my $cwd = getcwd();
|
2020-11-11 12:13:47 -05:00
|
|
|
debug(2, 0, "Cleaning up any invalid links in $dir (pwd=$cwd)");
|
2020-11-01 19:54:15 -05:00
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
if (not -d $dir) {
|
2020-11-11 14:42:28 -05:00
|
|
|
internal_error("cleanup_invalid_links() called with a non-directory: $dir");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
opendir my $DIR, $dir
|
2012-07-08 20:06:13 -04:00
|
|
|
or error("cannot read directory: $dir ($!)");
|
2011-11-24 11:28:09 -05:00
|
|
|
my @listing = readdir $DIR;
|
|
|
|
closedir $DIR;
|
|
|
|
|
|
|
|
NODE:
|
2024-04-06 08:33:53 -04:00
|
|
|
for my $node (sort @listing) {
|
2011-11-24 11:28:09 -05:00
|
|
|
next NODE if $node eq '.';
|
|
|
|
next NODE if $node eq '..';
|
|
|
|
|
|
|
|
my $node_path = join_paths($dir, $node);
|
|
|
|
|
2020-11-01 19:54:15 -05:00
|
|
|
next unless -l $node_path;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2020-11-11 12:13:47 -05:00
|
|
|
debug(4, 1, "Checking validity of link $node_path");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2020-11-01 19:54:15 -05:00
|
|
|
if (exists $self->{link_task_for}{$node_path}) {
|
2020-11-11 12:13:57 -05:00
|
|
|
my $action = $self->{link_task_for}{$node_path}{action};
|
|
|
|
if ($action ne 'remove') {
|
|
|
|
warn "Unexpected action $action scheduled for $node_path; skipping clean-up\n";
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
debug(4, 2, "$node_path scheduled for removal; skipping clean-up");
|
|
|
|
}
|
|
|
|
next;
|
2020-11-01 19:54:15 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
# Where is the link pointing?
|
|
|
|
# (don't use read_a_link() here)
|
2024-03-31 10:38:38 -04:00
|
|
|
my $link_dest = readlink($node_path);
|
|
|
|
if (not $link_dest) {
|
2020-11-01 19:54:15 -05:00
|
|
|
error("Could not read link $node_path");
|
|
|
|
}
|
|
|
|
|
2024-04-01 10:15:58 -04:00
|
|
|
my $target_subpath = join_paths($dir, $link_dest);
|
2024-03-31 10:38:38 -04:00
|
|
|
debug(4, 2, "join $dir $link_dest");
|
2024-04-01 10:15:58 -04:00
|
|
|
if (-e $target_subpath) {
|
|
|
|
debug(4, 2, "Link target $link_dest exists at $target_subpath; skipping clean up");
|
2020-11-01 19:54:15 -05:00
|
|
|
next;
|
|
|
|
}
|
2020-11-11 14:43:25 -05:00
|
|
|
else {
|
2024-04-01 10:15:58 -04:00
|
|
|
debug(4, 2, "Link target $link_dest doesn't exist at $target_subpath");
|
2020-11-11 14:43:25 -05:00
|
|
|
}
|
2020-11-01 19:54:15 -05:00
|
|
|
|
2020-11-11 12:13:47 -05:00
|
|
|
debug(3, 1,
|
2024-03-31 10:38:38 -04:00
|
|
|
"Checking whether valid link $node_path -> $link_dest is " .
|
2020-11-01 19:54:15 -05:00
|
|
|
"owned by stow");
|
|
|
|
|
2024-03-31 10:38:38 -04:00
|
|
|
my $owner = $self->link_owned_by_package($node_path, $link_dest);
|
2020-11-11 14:43:25 -05:00
|
|
|
if ($owner) {
|
2020-11-01 19:54:15 -05:00
|
|
|
# owned by stow
|
2020-11-11 14:43:25 -05:00
|
|
|
debug(2, 0, "--- removing link owned by $owner: $node_path => " .
|
2024-03-31 10:38:38 -04:00
|
|
|
join_paths($dir, $link_dest));
|
2020-11-01 19:54:15 -05:00
|
|
|
$self->do_unlink($node_path);
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2024-04-01 11:34:01 -04:00
|
|
|
=head2 foldable($target_subdir)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine whether a tree can be folded
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 11:34:01 -04:00
|
|
|
=item $target_subdir
|
2024-03-31 11:10:08 -04:00
|
|
|
|
2024-04-01 16:33:55 -04:00
|
|
|
Path to the target sub-directory to check for foldability, relative to
|
|
|
|
the current directory (the top-level target directory).
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns path to the parent dir iff the tree can be safely folded. The
|
2024-04-01 16:33:55 -04:00
|
|
|
path returned is relative to the parent of C<$target_subdir>, i.e. it
|
|
|
|
can be used as the source for a replacement symlink.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub foldable {
|
|
|
|
my $self = shift;
|
2024-04-01 11:34:01 -04:00
|
|
|
my ($target_subdir) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 11:34:01 -04:00
|
|
|
debug(3, 2, "Is $target_subdir foldable?");
|
2012-02-18 15:13:32 -05:00
|
|
|
if ($self->{'no-folding'}) {
|
2024-04-01 13:49:01 -04:00
|
|
|
debug(3, 3, "Not foldable because --no-folding enabled");
|
2012-02-18 15:13:32 -05:00
|
|
|
return '';
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 11:34:01 -04:00
|
|
|
opendir my $DIR, $target_subdir
|
|
|
|
or error(qq{Cannot read directory "$target_subdir" ($!)\n});
|
2011-11-24 11:28:09 -05:00
|
|
|
my @listing = readdir $DIR;
|
|
|
|
closedir $DIR;
|
|
|
|
|
2024-04-01 16:33:55 -04:00
|
|
|
# We want to see if all the symlinks in $target_subdir point to
|
|
|
|
# files under the same parent subdirectory in the package
|
|
|
|
# (e.g. ../../stow/pkg1/common_dir/file1). So remember which
|
|
|
|
# parent subdirectory we've already seen, and if we come across a
|
|
|
|
# second one which is different,
|
|
|
|
# (e.g. ../../stow/pkg2/common_dir/file2), then $target_subdir
|
|
|
|
# common_dir which contains file{1,2} cannot be folded to be
|
|
|
|
# a symlink to (say) ../../stow/pkg1/common_dir.
|
|
|
|
my $parent_in_pkg = '';
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
NODE:
|
2024-04-06 08:33:53 -04:00
|
|
|
for my $node (sort @listing) {
|
2011-11-24 11:28:09 -05:00
|
|
|
next NODE if $node eq '.';
|
|
|
|
next NODE if $node eq '..';
|
|
|
|
|
2024-04-01 14:57:54 -04:00
|
|
|
my $target_node_path = join_paths($target_subdir, $node);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Skip nodes scheduled for removal
|
2024-04-01 14:57:54 -04:00
|
|
|
next NODE if not $self->is_a_node($target_node_path);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# If it's not a link then we can't fold its parent
|
2024-04-01 14:57:54 -04:00
|
|
|
if (not $self->is_a_link($target_node_path)) {
|
|
|
|
debug(3, 3, "Not foldable because $target_node_path not a link");
|
2024-04-01 13:49:01 -04:00
|
|
|
return '';
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Where is the link pointing?
|
2024-04-01 16:33:55 -04:00
|
|
|
my $link_dest = $self->read_a_link($target_node_path);
|
|
|
|
if (not $link_dest) {
|
2024-04-01 14:57:54 -04:00
|
|
|
error("Could not read link $target_node_path");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 16:33:55 -04:00
|
|
|
my $new_parent = parent($link_dest);
|
|
|
|
if ($parent_in_pkg eq '') {
|
|
|
|
$parent_in_pkg = $new_parent;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 16:33:55 -04:00
|
|
|
elsif ($parent_in_pkg ne $new_parent) {
|
|
|
|
debug(3, 3, "Not foldable because $target_subdir contains links to entries in both $parent_in_pkg and $new_parent");
|
2011-11-24 11:28:09 -05:00
|
|
|
return '';
|
|
|
|
}
|
|
|
|
}
|
2024-04-01 16:33:55 -04:00
|
|
|
if (not $parent_in_pkg) {
|
|
|
|
debug(3, 3, "Not foldable because $target_subdir contains no links");
|
|
|
|
return '';
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 13:49:01 -04:00
|
|
|
# If we get here then all nodes inside $target_subdir are links,
|
|
|
|
# and those links point to nodes inside the same directory.
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
# chop of leading '..' to get the path to the common parent directory
|
2024-04-01 11:34:01 -04:00
|
|
|
# relative to the parent of our $target_subdir
|
2024-04-01 16:33:55 -04:00
|
|
|
$parent_in_pkg =~ s{\A\.\./}{};
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# If the resulting path is owned by stow, we can fold it
|
2024-04-01 16:33:55 -04:00
|
|
|
if ($self->link_owned_by_package($target_subdir, $parent_in_pkg)) {
|
2024-04-01 11:34:01 -04:00
|
|
|
debug(3, 3, "$target_subdir is foldable");
|
2024-04-01 16:33:55 -04:00
|
|
|
return $parent_in_pkg;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
2024-04-01 13:49:01 -04:00
|
|
|
debug(3, 3, "$target_subdir is not foldable");
|
2011-11-24 11:28:09 -05:00
|
|
|
return '';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 17:32:24 -04:00
|
|
|
=head2 fold_tree($target_subdir, $pkg_subpath)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Fold the given tree
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 17:32:24 -04:00
|
|
|
=item $target_subdir
|
2024-03-31 11:10:08 -04:00
|
|
|
|
2024-04-01 17:30:55 -04:00
|
|
|
Directory that we will replace with a link to $pkg_subpath.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
2024-04-01 17:30:55 -04:00
|
|
|
=item $pkg_subpath
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
link to the folded tree source
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Only called iff foldable() is true so we can remove some checks.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub fold_tree {
|
|
|
|
my $self = shift;
|
2024-04-01 17:32:24 -04:00
|
|
|
my ($target_subdir, $pkg_subpath) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 17:32:24 -04:00
|
|
|
debug(3, 0, "--- Folding tree: $target_subdir => $pkg_subpath");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 17:32:24 -04:00
|
|
|
opendir my $DIR, $target_subdir
|
|
|
|
or error(qq{Cannot read directory "$target_subdir" ($!)\n});
|
2011-11-24 11:28:09 -05:00
|
|
|
my @listing = readdir $DIR;
|
|
|
|
closedir $DIR;
|
|
|
|
|
|
|
|
NODE:
|
2024-04-06 08:33:53 -04:00
|
|
|
for my $node (sort @listing) {
|
2011-11-24 11:28:09 -05:00
|
|
|
next NODE if $node eq '.';
|
|
|
|
next NODE if $node eq '..';
|
2024-04-01 17:32:24 -04:00
|
|
|
next NODE if not $self->is_a_node(join_paths($target_subdir, $node));
|
|
|
|
$self->do_unlink(join_paths($target_subdir, $node));
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 17:32:24 -04:00
|
|
|
$self->do_rmdir($target_subdir);
|
|
|
|
$self->do_link($pkg_subpath, $target_subdir);
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 conflict($package, $message)
|
|
|
|
|
|
|
|
Handle conflicts in stow operations
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $package
|
|
|
|
|
|
|
|
the package involved with the conflicting operation
|
|
|
|
|
|
|
|
=item $message
|
|
|
|
|
|
|
|
a description of the conflict
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub conflict {
|
|
|
|
my $self = shift;
|
2011-11-24 17:49:22 -05:00
|
|
|
my ($action, $package, $message) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "CONFLICT when ${action}ing $package: $message");
|
2011-11-24 17:49:22 -05:00
|
|
|
$self->{conflicts}{$action}{$package} ||= [];
|
|
|
|
push @{ $self->{conflicts}{$action}{$package} }, $message;
|
|
|
|
$self->{conflict_count}++;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 get_conflicts()
|
|
|
|
|
2011-11-24 17:49:22 -05:00
|
|
|
Returns a nested hash of all potential conflicts discovered: the keys
|
|
|
|
are actions ('stow' or 'unstow'), and the values are hashrefs whose
|
|
|
|
keys are stow package names and whose values are conflict
|
|
|
|
descriptions, e.g.:
|
|
|
|
|
|
|
|
(
|
|
|
|
stow => {
|
|
|
|
perl => [
|
|
|
|
"existing target is not owned by stow: bin/a2p"
|
|
|
|
"existing target is neither a link nor a directory: bin/perl"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
)
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub get_conflicts {
|
|
|
|
my $self = shift;
|
2011-11-24 17:49:22 -05:00
|
|
|
return %{ $self->{conflicts} };
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 get_conflict_count()
|
|
|
|
|
|
|
|
Returns the number of conflicts found.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub get_conflict_count {
|
|
|
|
my $self = shift;
|
|
|
|
return $self->{conflict_count};
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
=head2 get_tasks()
|
|
|
|
|
|
|
|
Returns a list of all symlink/directory creation/removal tasks.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub get_tasks {
|
|
|
|
my $self = shift;
|
|
|
|
return @{ $self->{tasks} };
|
|
|
|
}
|
|
|
|
|
2011-11-24 17:49:22 -05:00
|
|
|
=head2 get_action_count()
|
|
|
|
|
|
|
|
Returns the number of actions planned for this Stow instance.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub get_action_count {
|
|
|
|
my $self = shift;
|
|
|
|
return $self->{action_count};
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 ignore($stow_path, $package, $target)
|
|
|
|
|
|
|
|
Determine if the given path matches a regex in our ignore list.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $stow_path
|
|
|
|
|
|
|
|
the stow directory containing the package
|
|
|
|
|
|
|
|
=item $package
|
|
|
|
|
|
|
|
the package containing the path
|
|
|
|
|
|
|
|
=item $target
|
|
|
|
|
|
|
|
the path to check against the ignore list relative to its package
|
|
|
|
directory
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns true iff the path should be ignored.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub ignore {
|
|
|
|
my $self = shift;
|
2011-11-23 18:45:48 -05:00
|
|
|
my ($stow_path, $package, $target) = @_;
|
|
|
|
|
|
|
|
internal_error(__PACKAGE__ . "::ignore() called with empty target")
|
|
|
|
unless length $target;
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
for my $suffix (@{ $self->{ignore} }) {
|
2011-11-23 18:45:48 -05:00
|
|
|
if ($target =~ m/$suffix/) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 1, "Ignoring path $target due to --ignore=$suffix");
|
2011-11-23 18:45:48 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-23 18:45:48 -05:00
|
|
|
my $package_dir = join_paths($stow_path, $package);
|
|
|
|
my ($path_regexp, $segment_regexp) =
|
|
|
|
$self->get_ignore_regexps($package_dir);
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(5, 2, "Ignore list regexp for paths: " .
|
2011-11-23 18:45:48 -05:00
|
|
|
(defined $path_regexp ? "/$path_regexp/" : "none"));
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(5, 2, "Ignore list regexp for segments: " .
|
2011-11-23 18:45:48 -05:00
|
|
|
(defined $segment_regexp ? "/$segment_regexp/" : "none"));
|
|
|
|
|
|
|
|
if (defined $path_regexp and "/$target" =~ $path_regexp) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 1, "Ignoring path /$target");
|
2011-11-23 18:45:48 -05:00
|
|
|
return 1;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2011-11-23 18:45:48 -05:00
|
|
|
|
|
|
|
(my $basename = $target) =~ s!.+/!!;
|
|
|
|
if (defined $segment_regexp and $basename =~ $segment_regexp) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 1, "Ignoring path segment $basename");
|
2011-11-23 18:45:48 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(5, 1, "Not ignoring $target");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-23 18:45:48 -05:00
|
|
|
sub get_ignore_regexps {
|
|
|
|
my $self = shift;
|
|
|
|
my ($dir) = @_;
|
|
|
|
|
|
|
|
# N.B. the local and global stow ignore files have to have different
|
|
|
|
# names so that:
|
|
|
|
# 1. the global one can be a symlink to within a stow
|
|
|
|
# package, managed by stow itself, and
|
|
|
|
# 2. the local ones can be ignored via hardcoded logic in
|
|
|
|
# GlobsToRegexp(), so that they always stay within their stow packages.
|
|
|
|
|
|
|
|
my $local_stow_ignore = join_paths($dir, $LOCAL_IGNORE_FILE);
|
|
|
|
my $global_stow_ignore = join_paths($ENV{HOME}, $GLOBAL_IGNORE_FILE);
|
|
|
|
|
|
|
|
for my $file ($local_stow_ignore, $global_stow_ignore) {
|
|
|
|
if (-e $file) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(5, 1, "Using ignore file: $file");
|
2011-11-23 18:45:48 -05:00
|
|
|
return $self->get_ignore_regexps_from_file($file);
|
|
|
|
}
|
|
|
|
else {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(5, 1, "$file didn't exist");
|
2011-11-23 18:45:48 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 1, "Using built-in ignore list");
|
2011-11-23 18:45:48 -05:00
|
|
|
return @default_global_ignore_regexps;
|
|
|
|
}
|
|
|
|
|
|
|
|
my %ignore_file_regexps;
|
|
|
|
|
|
|
|
sub get_ignore_regexps_from_file {
|
|
|
|
my $self = shift;
|
|
|
|
my ($file) = @_;
|
|
|
|
|
|
|
|
if (exists $ignore_file_regexps{$file}) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 2, "Using memoized regexps from $file");
|
2011-11-23 18:45:48 -05:00
|
|
|
return @{ $ignore_file_regexps{$file} };
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! open(REGEXPS, $file)) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 2, "Failed to open $file: $!");
|
2011-11-23 18:45:48 -05:00
|
|
|
return undef;
|
|
|
|
}
|
|
|
|
|
|
|
|
my @regexps = $self->get_ignore_regexps_from_fh(\*REGEXPS);
|
|
|
|
close(REGEXPS);
|
|
|
|
|
|
|
|
$ignore_file_regexps{$file} = [ @regexps ];
|
|
|
|
return @regexps;
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 invalidate_memoized_regexp($file)
|
|
|
|
|
|
|
|
For efficiency of performance, regular expressions are compiled from
|
|
|
|
each ignore list file the first time it is used by the Stow process,
|
|
|
|
and then memoized for future use. If you expect the contents of these
|
|
|
|
files to change during a single run, you will need to invalidate the
|
|
|
|
memoized value from this cache. This method allows you to do that.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub invalidate_memoized_regexp {
|
|
|
|
my $self = shift;
|
|
|
|
my ($file) = @_;
|
|
|
|
if (exists $ignore_file_regexps{$file}) {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 2, "Invalidated memoized regexp for $file");
|
2011-11-23 18:45:48 -05:00
|
|
|
delete $ignore_file_regexps{$file};
|
|
|
|
}
|
|
|
|
else {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 1, "WARNING: no memoized regexp for $file to invalidate");
|
2011-11-23 18:45:48 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sub get_ignore_regexps_from_fh {
|
|
|
|
my $self = shift;
|
|
|
|
my ($fh) = @_;
|
|
|
|
my %regexps;
|
|
|
|
while (<$fh>) {
|
|
|
|
chomp;
|
|
|
|
s/^\s+//;
|
|
|
|
s/\s+$//;
|
|
|
|
next if /^#/ or length($_) == 0;
|
|
|
|
s/\s+#.+//; # strip comments to right of pattern
|
|
|
|
s/\\#/#/g;
|
|
|
|
$regexps{$_}++;
|
|
|
|
}
|
|
|
|
|
|
|
|
# Local ignore lists should *always* stay within the stow directory,
|
|
|
|
# because this is the only place stow looks for them.
|
|
|
|
$regexps{"^/\Q$LOCAL_IGNORE_FILE\E\$"}++;
|
|
|
|
|
|
|
|
return $self->compile_ignore_regexps(%regexps);
|
|
|
|
}
|
|
|
|
|
|
|
|
sub compile_ignore_regexps {
|
|
|
|
my $self = shift;
|
|
|
|
my (%regexps) = @_;
|
|
|
|
|
|
|
|
my @segment_regexps;
|
|
|
|
my @path_regexps;
|
|
|
|
for my $regexp (keys %regexps) {
|
|
|
|
if (index($regexp, '/') < 0) {
|
|
|
|
# No / found in regexp, so use it for matching against basename
|
|
|
|
push @segment_regexps, $regexp;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
# / found in regexp, so use it for matching against full path
|
|
|
|
push @path_regexps, $regexp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
my $segment_regexp = join '|', @segment_regexps;
|
|
|
|
my $path_regexp = join '|', @path_regexps;
|
|
|
|
$segment_regexp = @segment_regexps ?
|
|
|
|
$self->compile_regexp("^($segment_regexp)\$") : undef;
|
|
|
|
$path_regexp = @path_regexps ?
|
|
|
|
$self->compile_regexp("(^|/)($path_regexp)(/|\$)") : undef;
|
|
|
|
|
|
|
|
return ($path_regexp, $segment_regexp);
|
|
|
|
}
|
|
|
|
|
|
|
|
sub compile_regexp {
|
|
|
|
my $self = shift;
|
|
|
|
my ($regexp) = @_;
|
|
|
|
my $compiled = eval { qr/$regexp/ };
|
|
|
|
die "Failed to compile regexp: $@\n" if $@;
|
|
|
|
return $compiled;
|
|
|
|
}
|
|
|
|
|
|
|
|
sub get_default_global_ignore_regexps {
|
|
|
|
my $class = shift;
|
|
|
|
# Bootstrap issue - first time we stow, we will be stowing
|
|
|
|
# .cvsignore so it might not exist in ~ yet, or if it does, it could
|
|
|
|
# be an old version missing the entries we need. So we make sure
|
|
|
|
# they are there by hardcoding some crucial entries.
|
|
|
|
return $class->get_ignore_regexps_from_fh(\*DATA);
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 defer($path)
|
|
|
|
|
|
|
|
Determine if the given path matches a regex in our C<defer> list
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $path
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns boolean.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub defer {
|
|
|
|
my $self = shift;
|
|
|
|
my ($path) = @_;
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
for my $prefix (@{ $self->{defer} }) {
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1 if $path =~ m/$prefix/;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 override($path)
|
|
|
|
|
|
|
|
Determine if the given path matches a regex in our C<override> list
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $path
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns boolean
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub override {
|
|
|
|
my $self = shift;
|
|
|
|
my ($path) = @_;
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
for my $regex (@{ $self->{override} }) {
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1 if $path =~ m/$regex/;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
##############################################################################
|
|
|
|
#
|
|
|
|
# The following code provides the abstractions that allow us to defer operating
|
|
|
|
# on the filesystem until after all potential conflcits have been assessed.
|
|
|
|
#
|
|
|
|
##############################################################################
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 process_tasks()
|
|
|
|
|
|
|
|
Process each task in the tasks list
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item none
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns : n/a
|
|
|
|
Throws : fatal error if tasks list is corrupted or a task fails
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub process_tasks {
|
|
|
|
my $self = shift;
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "Processing tasks...");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Strip out all tasks with a skip action
|
2011-11-23 19:45:29 -05:00
|
|
|
$self->{tasks} = [ grep { $_->{action} ne 'skip' } @{ $self->{tasks} } ];
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
if (not @{ $self->{tasks} }) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$self->within_target_do(sub {
|
|
|
|
for my $task (@{ $self->{tasks} }) {
|
|
|
|
$self->process_task($task);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(2, 0, "Processing tasks... done");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 process_task($task)
|
|
|
|
|
|
|
|
Process a single task.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $task => the task to process
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns : n/a
|
|
|
|
Throws : fatal error if task fails
|
|
|
|
# #
|
|
|
|
Must run from within target directory. Task involve either creating
|
|
|
|
or deleting dirs and symlinks an action is set to 'skip' if it is
|
|
|
|
found to be redundant
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub process_task {
|
|
|
|
my $self = shift;
|
|
|
|
my ($task) = @_;
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task->{action} eq 'create') {
|
|
|
|
if ($task->{type} eq 'dir') {
|
|
|
|
mkdir($task->{path}, 0777)
|
2012-07-08 20:06:13 -04:00
|
|
|
or error("Could not create directory: $task->{path} ($!)");
|
2012-01-09 16:25:35 -05:00
|
|
|
return;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task->{type} eq 'link') {
|
|
|
|
symlink $task->{source}, $task->{path}
|
2011-11-24 11:28:09 -05:00
|
|
|
or error(
|
2012-07-08 20:06:13 -04:00
|
|
|
"Could not create symlink: %s => %s ($!)",
|
2011-11-23 19:45:29 -05:00
|
|
|
$task->{path},
|
|
|
|
$task->{source}
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
2012-01-09 16:25:35 -05:00
|
|
|
return;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task->{action} eq 'remove') {
|
|
|
|
if ($task->{type} eq 'dir') {
|
|
|
|
rmdir $task->{path}
|
2012-07-08 20:06:13 -04:00
|
|
|
or error("Could not remove directory: $task->{path} ($!)");
|
2012-01-09 16:25:35 -05:00
|
|
|
return;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task->{type} eq 'link') {
|
|
|
|
unlink $task->{path}
|
2012-07-08 20:06:13 -04:00
|
|
|
or error("Could not remove link: $task->{path} ($!)");
|
2012-01-09 16:25:35 -05:00
|
|
|
return;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
2012-01-09 16:25:35 -05:00
|
|
|
elsif ($task->{action} eq 'move') {
|
|
|
|
if ($task->{type} eq 'file') {
|
|
|
|
# rename() not good enough, since the stow directory
|
|
|
|
# might be on a different filesystem to the target.
|
|
|
|
move $task->{path}, $task->{dest}
|
2012-07-08 20:06:13 -04:00
|
|
|
or error("Could not move $task->{path} -> $task->{dest} ($!)");
|
2012-01-09 16:25:35 -05:00
|
|
|
return;
|
|
|
|
}
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2012-01-09 16:25:35 -05:00
|
|
|
|
|
|
|
# Should never happen.
|
2012-07-08 20:06:13 -04:00
|
|
|
internal_error("bad task action: $task->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 link_task_action($path)
|
|
|
|
|
|
|
|
Finds the link task action for the given path, if there is one
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $path
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns C<'remove'>, C<'create'>, or C<''> if there is no action.
|
|
|
|
Throws a fatal exception if an invalid action is found.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub link_task_action {
|
|
|
|
my $self = shift;
|
|
|
|
my ($path) = @_;
|
|
|
|
|
|
|
|
if (! exists $self->{link_task_for}{$path}) {
|
2024-04-01 16:32:30 -04:00
|
|
|
debug(4, 4, "| link_task_action($path): no task");
|
2011-11-24 11:28:09 -05:00
|
|
|
return '';
|
|
|
|
}
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
my $action = $self->{link_task_for}{$path}->{action};
|
2011-11-24 11:28:09 -05:00
|
|
|
internal_error("bad task action: $action")
|
|
|
|
unless $action eq 'remove' or $action eq 'create';
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(4, 1, "link_task_action($path): link task exists with action $action");
|
2011-11-24 11:28:09 -05:00
|
|
|
return $action;
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 dir_task_action($path)
|
|
|
|
|
|
|
|
Finds the dir task action for the given path, if there is one.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $path
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns C<'remove'>, C<'create'>, or C<''> if there is no action.
|
|
|
|
Throws a fatal exception if an invalid action is found.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub dir_task_action {
|
|
|
|
my $self = shift;
|
|
|
|
my ($path) = @_;
|
|
|
|
|
|
|
|
if (! exists $self->{dir_task_for}{$path}) {
|
2024-04-01 16:32:30 -04:00
|
|
|
debug(4, 4, "| dir_task_action($path): no task");
|
2011-11-24 11:28:09 -05:00
|
|
|
return '';
|
|
|
|
}
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
my $action = $self->{dir_task_for}{$path}->{action};
|
2011-11-24 11:28:09 -05:00
|
|
|
internal_error("bad task action: $action")
|
|
|
|
unless $action eq 'remove' or $action eq 'create';
|
|
|
|
|
2024-04-01 16:32:30 -04:00
|
|
|
debug(4, 4, "| dir_task_action($path): dir task exists with action $action");
|
2011-11-24 11:28:09 -05:00
|
|
|
return $action;
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=head2 parent_link_scheduled_for_removal($target_path)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine whether the given path or any parent thereof is a link
|
|
|
|
scheduled for removal
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=item $target_path
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns boolean
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub parent_link_scheduled_for_removal {
|
|
|
|
my $self = shift;
|
2024-04-01 18:37:06 -04:00
|
|
|
my ($target_path) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
my $prefix = '';
|
2024-04-01 18:37:06 -04:00
|
|
|
for my $part (split m{/+}, $target_path) {
|
2011-11-24 11:28:09 -05:00
|
|
|
$prefix = join_paths($prefix, $part);
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(5, 4, "| parent_link_scheduled_for_removal($target_path): prefix $prefix");
|
2011-11-24 11:28:09 -05:00
|
|
|
if (exists $self->{link_task_for}{$prefix} and
|
2011-11-23 19:45:29 -05:00
|
|
|
$self->{link_task_for}{$prefix}->{action} eq 'remove') {
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 4, "| parent_link_scheduled_for_removal($target_path): link scheduled for removal");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 4, "| parent_link_scheduled_for_removal($target_path): returning false");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=head2 is_a_link($target_path)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine if the given path is a current or planned link.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=item $target_path
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns false if an existing link is scheduled for removal and true if
|
|
|
|
a non-existent link is scheduled for creation.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub is_a_link {
|
|
|
|
my $self = shift;
|
2024-04-01 18:37:06 -04:00
|
|
|
my ($target_path) = @_;
|
|
|
|
debug(4, 2, "is_a_link($target_path)");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
if (my $action = $self->link_task_action($target_path)) {
|
2011-11-24 11:28:09 -05:00
|
|
|
if ($action eq 'remove') {
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 2, "is_a_link($target_path): returning 0 (remove action found)");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
elsif ($action eq 'create') {
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 2, "is_a_link($target_path): returning 1 (create action found)");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
if (-l $target_path) {
|
2011-11-21 18:21:48 -05:00
|
|
|
# Check if any of its parent are links scheduled for removal
|
2011-11-24 11:28:09 -05:00
|
|
|
# (need this for edge case during unfolding)
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 2, "is_a_link($target_path): is a real link");
|
|
|
|
return $self->parent_link_scheduled_for_removal($target_path) ? 0 : 1;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 2, "is_a_link($target_path): returning 0");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=head2 is_a_dir($target_path)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine if the given path is a current or planned directory
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=item $target_path
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns false if an existing directory is scheduled for removal and
|
|
|
|
true if a non-existent directory is scheduled for creation. We also
|
|
|
|
need to be sure we are not just following a link.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub is_a_dir {
|
|
|
|
my $self = shift;
|
2024-04-01 18:37:06 -04:00
|
|
|
my ($target_path) = @_;
|
|
|
|
debug(4, 1, "is_a_dir($target_path)");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
if (my $action = $self->dir_task_action($target_path)) {
|
2011-11-24 11:28:09 -05:00
|
|
|
if ($action eq 'remove') {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
elsif ($action eq 'create') {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
return 0 if $self->parent_link_scheduled_for_removal($target_path);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
if (-d $target_path) {
|
|
|
|
debug(4, 1, "is_a_dir($target_path): real dir");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 1, "is_a_dir($target_path): returning false");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=head2 is_a_node($target_path)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Determine whether the given path is a current or planned node.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
=item $target_path
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns false if an existing node is scheduled for removal, or true if
|
|
|
|
a non-existent node is scheduled for creation. We also need to be
|
|
|
|
sure we are not just following a link.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub is_a_node {
|
|
|
|
my $self = shift;
|
2024-04-01 18:37:06 -04:00
|
|
|
my ($target_path) = @_;
|
|
|
|
debug(4, 4, "| Checking whether $target_path is a current/planned node");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
my $laction = $self->link_task_action($target_path);
|
|
|
|
my $daction = $self->dir_task_action($target_path);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
if ($laction eq 'remove') {
|
|
|
|
if ($daction eq 'remove') {
|
2024-04-01 18:37:06 -04:00
|
|
|
internal_error("removing link and dir: $target_path");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
elsif ($daction eq 'create') {
|
2024-04-01 18:37:06 -04:00
|
|
|
# Assume that we're unfolding $target_path, and that the link
|
2011-11-24 11:28:09 -05:00
|
|
|
# removal action is earlier than the dir creation action
|
|
|
|
# in the task queue. FIXME: is this a safe assumption?
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else { # no dir action
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
elsif ($laction eq 'create') {
|
|
|
|
if ($daction eq 'remove') {
|
2024-04-01 18:37:06 -04:00
|
|
|
# Assume that we're folding $target_path, and that the dir
|
2011-11-24 11:28:09 -05:00
|
|
|
# removal action is earlier than the link creation action
|
|
|
|
# in the task queue. FIXME: is this a safe assumption?
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
elsif ($daction eq 'create') {
|
2024-04-01 18:37:06 -04:00
|
|
|
internal_error("creating link and dir: $target_path");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else { # no dir action
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
# No link action
|
|
|
|
if ($daction eq 'remove') {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
elsif ($daction eq 'create') {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else { # no dir action
|
|
|
|
# fall through to below
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
return 0 if $self->parent_link_scheduled_for_removal($target_path);
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
if (-e $target_path) {
|
|
|
|
debug(4, 3, "| is_a_node($target_path): really exists");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2024-04-01 18:37:06 -04:00
|
|
|
debug(4, 3, "| is_a_node($target_path): returning false");
|
2011-11-24 11:28:09 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-04-01 14:53:56 -04:00
|
|
|
=head2 read_a_link($link)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
2024-04-01 14:53:56 -04:00
|
|
|
Return the destination of a current or planned link.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-04-01 14:53:56 -04:00
|
|
|
=item $link
|
2024-03-31 11:10:08 -04:00
|
|
|
|
2024-04-01 14:53:56 -04:00
|
|
|
Path to the link target.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
2024-04-01 14:53:56 -04:00
|
|
|
Returns the destination of the given link. Throws a fatal exception
|
|
|
|
if the given path is not a current or planned link.
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub read_a_link {
|
|
|
|
my $self = shift;
|
2024-04-01 14:53:56 -04:00
|
|
|
my ($link) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-04-01 14:53:56 -04:00
|
|
|
if (my $action = $self->link_task_action($link)) {
|
2024-04-01 16:32:30 -04:00
|
|
|
debug(4, 2, "read_a_link($link): task exists with action $action");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
if ($action eq 'create') {
|
2024-04-01 14:53:56 -04:00
|
|
|
return $self->{link_task_for}{$link}->{source};
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
elsif ($action eq 'remove') {
|
|
|
|
internal_error(
|
2024-04-01 14:53:56 -04:00
|
|
|
"read_a_link() passed a path that is scheduled for removal: $link"
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
2024-04-01 14:53:56 -04:00
|
|
|
elsif (-l $link) {
|
2024-04-07 08:08:27 -04:00
|
|
|
debug(4, 2, "read_a_link($link): is a real link");
|
2024-04-01 14:53:56 -04:00
|
|
|
my $link_dest = readlink $link or error("Could not read link: $link ($!)");
|
|
|
|
return $link_dest;
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
2024-04-01 14:53:56 -04:00
|
|
|
internal_error("read_a_link() passed a non-link path: $link\n");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
2024-03-31 19:34:19 -04:00
|
|
|
=head2 do_link($link_dest, $link_src)
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
Wrap 'link' operation for later processing
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2024-03-31 19:34:19 -04:00
|
|
|
=item $link_dest
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
the existing file to link to
|
|
|
|
|
2024-03-31 19:34:19 -04:00
|
|
|
=item $link_src
|
2024-03-31 11:10:08 -04:00
|
|
|
|
|
|
|
the file to link
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Throws an error if this clashes with an existing planned operation.
|
|
|
|
Cleans up operations that undo previous operations.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub do_link {
|
|
|
|
my $self = shift;
|
2024-03-31 19:34:19 -04:00
|
|
|
my ($link_dest, $link_src) = @_;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2024-03-31 19:34:19 -04:00
|
|
|
if (exists $self->{dir_task_for}{$link_src}) {
|
|
|
|
my $task_ref = $self->{dir_task_for}{$link_src};
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task_ref->{action} eq 'create') {
|
|
|
|
if ($task_ref->{type} eq 'dir') {
|
2011-11-24 11:28:09 -05:00
|
|
|
internal_error(
|
|
|
|
"new link (%s => %s) clashes with planned new directory",
|
2024-03-31 19:34:19 -04:00
|
|
|
$link_src,
|
|
|
|
$link_dest,
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task_ref->{action} eq 'remove') {
|
2011-11-21 18:21:48 -05:00
|
|
|
# We may need to remove a directory before creating a link so continue.
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
2011-11-23 19:45:29 -05:00
|
|
|
internal_error("bad task action: $task_ref->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-03-31 19:34:19 -04:00
|
|
|
if (exists $self->{link_task_for}{$link_src}) {
|
|
|
|
my $task_ref = $self->{link_task_for}{$link_src};
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task_ref->{action} eq 'create') {
|
2024-03-31 19:34:19 -04:00
|
|
|
if ($task_ref->{source} ne $link_dest) {
|
2011-11-24 11:28:09 -05:00
|
|
|
internal_error(
|
|
|
|
"new link clashes with planned new link: %s => %s",
|
2011-11-23 19:45:29 -05:00
|
|
|
$task_ref->{path},
|
|
|
|
$task_ref->{source},
|
2011-11-24 11:28:09 -05:00
|
|
|
)
|
|
|
|
}
|
|
|
|
else {
|
2024-03-31 19:34:19 -04:00
|
|
|
debug(1, 0, "LINK: $link_src => $link_dest (duplicates previous action)");
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task_ref->{action} eq 'remove') {
|
2024-03-31 19:34:19 -04:00
|
|
|
if ($task_ref->{source} eq $link_dest) {
|
2011-11-21 18:21:48 -05:00
|
|
|
# No need to remove a link we are going to recreate
|
2024-03-31 19:34:19 -04:00
|
|
|
debug(1, 0, "LINK: $link_src => $link_dest (reverts previous action)");
|
|
|
|
$self->{link_task_for}{$link_src}->{action} = 'skip';
|
|
|
|
delete $self->{link_task_for}{$link_src};
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
2011-11-21 18:21:48 -05:00
|
|
|
# We may need to remove a link to replace it so continue
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
2011-11-23 19:45:29 -05:00
|
|
|
internal_error("bad task action: $task_ref->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Creating a new link
|
2024-03-31 19:34:19 -04:00
|
|
|
debug(1, 0, "LINK: $link_src => $link_dest");
|
2011-11-24 11:28:09 -05:00
|
|
|
my $task = {
|
|
|
|
action => 'create',
|
|
|
|
type => 'link',
|
2024-03-31 19:34:19 -04:00
|
|
|
path => $link_src,
|
|
|
|
source => $link_dest,
|
2011-11-24 11:28:09 -05:00
|
|
|
};
|
|
|
|
push @{ $self->{tasks} }, $task;
|
2024-03-31 19:34:19 -04:00
|
|
|
$self->{link_task_for}{$link_src} = $task;
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 do_unlink($file)
|
|
|
|
|
|
|
|
Wrap 'unlink' operation for later processing
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $file
|
|
|
|
|
|
|
|
the file to unlink
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Throws an error if this clashes with an existing planned operation.
|
|
|
|
Will remove an existing planned link.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub do_unlink {
|
|
|
|
my $self = shift;
|
|
|
|
my ($file) = @_;
|
|
|
|
|
|
|
|
if (exists $self->{link_task_for}{$file}) {
|
|
|
|
my $task_ref = $self->{link_task_for}{$file};
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task_ref->{action} eq 'remove') {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "UNLINK: $file (duplicates previous action)");
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task_ref->{action} eq 'create') {
|
2011-11-21 18:21:48 -05:00
|
|
|
# Do need to create a link then remove it
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "UNLINK: $file (reverts previous action)");
|
2011-11-23 19:45:29 -05:00
|
|
|
$self->{link_task_for}{$file}->{action} = 'skip';
|
2011-11-24 11:28:09 -05:00
|
|
|
delete $self->{link_task_for}{$file};
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
else {
|
2011-11-23 19:45:29 -05:00
|
|
|
internal_error("bad task action: $task_ref->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (exists $self->{dir_task_for}{$file} and $self->{dir_task_for}{$file} eq 'create') {
|
|
|
|
internal_error(
|
|
|
|
"new unlink operation clashes with planned operation: %s dir %s",
|
2011-11-23 19:45:29 -05:00
|
|
|
$self->{dir_task_for}{$file}->{action},
|
2011-11-24 11:28:09 -05:00
|
|
|
$file
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2011-11-21 18:21:48 -05:00
|
|
|
# Remove the link
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "UNLINK: $file");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
2012-07-08 20:06:13 -04:00
|
|
|
my $source = readlink $file or error("could not readlink $file ($!)");
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
my $task = {
|
|
|
|
action => 'remove',
|
|
|
|
type => 'link',
|
|
|
|
path => $file,
|
|
|
|
source => $source,
|
|
|
|
};
|
|
|
|
push @{ $self->{tasks} }, $task;
|
|
|
|
$self->{link_task_for}{$file} = $task;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 do_mkdir($dir)
|
|
|
|
|
|
|
|
Wrap 'mkdir' operation
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $dir
|
|
|
|
|
|
|
|
the directory to remove
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Throws a fatal exception if operation fails. Outputs a message if
|
|
|
|
'verbose' option is set. Does not perform operation if 'simulate'
|
|
|
|
option is set. Cleans up operations that undo previous operations.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub do_mkdir {
|
|
|
|
my $self = shift;
|
|
|
|
my ($dir) = @_;
|
|
|
|
|
|
|
|
if (exists $self->{link_task_for}{$dir}) {
|
|
|
|
my $task_ref = $self->{link_task_for}{$dir};
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task_ref->{action} eq 'create') {
|
2011-11-24 11:28:09 -05:00
|
|
|
internal_error(
|
|
|
|
"new dir clashes with planned new link (%s => %s)",
|
2011-11-23 19:45:29 -05:00
|
|
|
$task_ref->{path},
|
|
|
|
$task_ref->{source},
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task_ref->{action} eq 'remove') {
|
2011-11-21 18:21:48 -05:00
|
|
|
# May need to remove a link before creating a directory so continue
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
else {
|
2011-11-23 19:45:29 -05:00
|
|
|
internal_error("bad task action: $task_ref->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (exists $self->{dir_task_for}{$dir}) {
|
|
|
|
my $task_ref = $self->{dir_task_for}{$dir};
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task_ref->{action} eq 'create') {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "MKDIR: $dir (duplicates previous action)");
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task_ref->{action} eq 'remove') {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "MKDIR: $dir (reverts previous action)");
|
2011-11-23 19:45:29 -05:00
|
|
|
$self->{dir_task_for}{$dir}->{action} = 'skip';
|
2011-11-24 11:28:09 -05:00
|
|
|
delete $self->{dir_task_for}{$dir};
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
else {
|
2011-11-23 19:45:29 -05:00
|
|
|
internal_error("bad task action: $task_ref->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "MKDIR: $dir");
|
2011-11-24 11:28:09 -05:00
|
|
|
my $task = {
|
|
|
|
action => 'create',
|
|
|
|
type => 'dir',
|
|
|
|
path => $dir,
|
|
|
|
source => undef,
|
|
|
|
};
|
|
|
|
push @{ $self->{tasks} }, $task;
|
|
|
|
$self->{dir_task_for}{$dir} = $task;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 do_rmdir($dir)
|
|
|
|
|
|
|
|
Wrap 'rmdir' operation
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $dir
|
|
|
|
|
|
|
|
the directory to remove
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Throws a fatal exception if operation fails. Outputs a message if
|
|
|
|
'verbose' option is set. Does not perform operation if 'simulate'
|
|
|
|
option is set.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub do_rmdir {
|
|
|
|
my $self = shift;
|
|
|
|
my ($dir) = @_;
|
|
|
|
|
|
|
|
if (exists $self->{link_task_for}{$dir}) {
|
|
|
|
my $task_ref = $self->{link_task_for}{$dir};
|
|
|
|
internal_error(
|
|
|
|
"rmdir clashes with planned operation: %s link %s => %s",
|
2011-11-23 19:45:29 -05:00
|
|
|
$task_ref->{action},
|
|
|
|
$task_ref->{path},
|
|
|
|
$task_ref->{source}
|
2011-11-24 11:28:09 -05:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (exists $self->{dir_task_for}{$dir}) {
|
|
|
|
my $task_ref = $self->{link_task_for}{$dir};
|
|
|
|
|
2011-11-23 19:45:29 -05:00
|
|
|
if ($task_ref->{action} eq 'remove') {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "RMDIR $dir (duplicates previous action)");
|
2011-11-24 11:28:09 -05:00
|
|
|
return;
|
|
|
|
}
|
2011-11-23 19:45:29 -05:00
|
|
|
elsif ($task_ref->{action} eq 'create') {
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "MKDIR $dir (reverts previous action)");
|
2011-11-23 19:45:29 -05:00
|
|
|
$self->{link_task_for}{$dir}->{action} = 'skip';
|
2011-11-24 11:28:09 -05:00
|
|
|
delete $self->{link_task_for}{$dir};
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
else {
|
2011-11-23 19:45:29 -05:00
|
|
|
internal_error("bad task action: $task_ref->{action}");
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "RMDIR $dir");
|
2011-11-24 11:28:09 -05:00
|
|
|
my $task = {
|
|
|
|
action => 'remove',
|
|
|
|
type => 'dir',
|
|
|
|
path => $dir,
|
|
|
|
source => '',
|
|
|
|
};
|
|
|
|
push @{ $self->{tasks} }, $task;
|
|
|
|
$self->{dir_task_for}{$dir} = $task;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-03-31 11:10:08 -04:00
|
|
|
=head2 do_mv($src, $dst)
|
|
|
|
|
|
|
|
Wrap 'move' operation for later processing.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $src
|
|
|
|
|
|
|
|
the file to move
|
|
|
|
|
|
|
|
=item $dst
|
|
|
|
|
|
|
|
the path to move it to
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Throws an error if this clashes with an existing planned operation.
|
|
|
|
Alters contents of package installation image in stow dir.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2012-01-09 16:25:35 -05:00
|
|
|
sub do_mv {
|
|
|
|
my $self = shift;
|
|
|
|
my ($src, $dst) = @_;
|
|
|
|
|
|
|
|
if (exists $self->{link_task_for}{$src}) {
|
|
|
|
# I don't *think* this should ever happen, but I'm not
|
|
|
|
# 100% sure.
|
|
|
|
my $task_ref = $self->{link_task_for}{$src};
|
|
|
|
internal_error(
|
|
|
|
"do_mv: pre-existing link task for $src; action: %s, source: %s",
|
|
|
|
$task_ref->{action}, $task_ref->{source}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
elsif (exists $self->{dir_task_for}{$src}) {
|
|
|
|
my $task_ref = $self->{dir_task_for}{$src};
|
|
|
|
internal_error(
|
|
|
|
"do_mv: pre-existing dir task for %s?! action: %s",
|
|
|
|
$src, $task_ref->{action}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
# Remove the link
|
2020-11-01 16:04:22 -05:00
|
|
|
debug(1, 0, "MV: $src -> $dst");
|
2012-01-09 16:25:35 -05:00
|
|
|
|
|
|
|
my $task = {
|
|
|
|
action => 'move',
|
|
|
|
type => 'file',
|
|
|
|
path => $src,
|
|
|
|
dest => $dst,
|
|
|
|
};
|
|
|
|
push @{ $self->{tasks} }, $task;
|
|
|
|
|
|
|
|
# FIXME: do we need this for anything?
|
|
|
|
#$self->{mv_task_for}{$file} = $task;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
|
|
|
|
#############################################################################
|
|
|
|
#
|
|
|
|
# End of methods; subroutines follow.
|
|
|
|
# FIXME: Ideally these should be in a separate module.
|
|
|
|
|
|
|
|
|
2024-03-31 10:33:14 -04:00
|
|
|
# ===== PRIVATE SUBROUTINE ===================================================
|
2011-11-24 11:28:09 -05:00
|
|
|
# Name : internal_error()
|
|
|
|
# Purpose : output internal error message in a consistent form and die
|
2024-03-31 11:10:08 -04:00
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $message => error message to output
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Returns : n/a
|
|
|
|
Throws : n/a
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2011-11-24 11:28:09 -05:00
|
|
|
sub internal_error {
|
|
|
|
my ($format, @args) = @_;
|
2012-01-09 12:52:11 -05:00
|
|
|
my $error = sprintf($format, @args);
|
2012-01-09 16:11:58 -05:00
|
|
|
my $stacktrace = Carp::longmess();
|
2012-01-09 12:52:11 -05:00
|
|
|
die <<EOF;
|
2012-01-09 16:11:58 -05:00
|
|
|
|
|
|
|
$ProgramName: INTERNAL ERROR: $error$stacktrace
|
|
|
|
|
2012-01-09 12:52:11 -05:00
|
|
|
This _is_ a bug. Please submit a bug report so we can fix it! :-)
|
|
|
|
See http://www.gnu.org/software/stow/ for how to do this.
|
|
|
|
EOF
|
2011-11-24 11:28:09 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
=head1 BUGS
|
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# Local variables:
|
|
|
|
# mode: perl
|
|
|
|
# end:
|
|
|
|
# vim: ft=perl
|
2011-11-23 18:45:48 -05:00
|
|
|
|
|
|
|
#############################################################################
|
|
|
|
# Default global list of ignore regexps follows
|
|
|
|
# (automatically appended by the Makefile)
|
|
|
|
|
|
|
|
__DATA__
|