Today I tried to move my ttree production to another directory and
thought: "Well, that's easy. Just point the 'dest' parameter to the
new location and run ttree".
To my surprise some of the files (and subdirs) would not be created.
I examined ttree and found the culprit around line 260:
(undef, undef, $mode, undef, $uid, $gid, undef, undef,
undef, undef, undef, undef, undef) = stat($abspath);
# create target directory if required
$target = "$destdir/$path";
unless (-d $target || $dryrun) {
mkdir $target, $mode || do {
warn "mkdir ($target): $!\n";
next;
};
...that is, new directories are created in $destdir with the same
permissions as their origins had in $abspath.
If, for some reason - maybe even intentionally - the source directory
is readonly, then the output directory is created readonly as well.
Tough luck for all files and subdirs within such directories.
I feel that one would want to set the permissions of the output tree
to be different than those of the input tree in many cases.
I could submit a patch which
- either treats freshly created directories according to the
"preserve" option. This, however, has another gotcha: Files are
chmodded after they have been created. Hence it works perfectly to
have input files readonly *and* preserve set to true (at least
once). For directories, changing the permissions would have to be
done after they have been completely processed.
- or drops $mode handling for directories altogether, relying on a
decent umask.
Any opinions?
--
Cheers,
haj
_______________________________________________
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
