dagolden/path-tiny

File path utility

HOW TO CONTRIBUTE

Thank you for considering contributing to this distribution. This file contains instructions that will help you work with the source code.

The distribution is managed with Dist::Zilla. This means that many of the usual files you might expect are not in the repository, but are generated at release time, as is much of the documentation. Some generated files are kept in the repository as a convenience (e.g. Makefile.PL or cpanfile).

Generally, you do not need Dist::Zilla to contribute patches. You do need Dist::Zilla to create a tarball. See below for guidance.

Getting dependencies

If you have App::cpanminus 1.6 or later installed, you can use cpanm to satisfy dependencies like this:

$ cpanm --installdeps .

Otherwise, look for either a Makefile.PL or cpanfile file for a list of dependencies to satisfy.

Running tests

You can run tests directly using the prove tool:

$ prove -l
$ prove -lv t/some_test_file.t

For most of my distributions, prove is entirely sufficient for you to test any patches you have. I use prove for 99% of my testing during development.

Code style and tidying

Please try to match any existing coding style. If there is a .perltidyrc file, please install Perl::Tidy and use perltidy before submitting patches.

If there is a tidyall.ini file, you can also install Code::TidyAll and run tidyall on a file or tidyall -a to tidy all files.

Patching documentation

Much of the documentation Pod is generated at release time. Some is generated boilerplate; other documentation is built from pseudo-POD directives in the source like C<=method> or C<=func>.

If you would like to submit a documentation edit, please limit yourself to the documentation you see.

If you see typos or documentation issues in the generated docs, please email or open a bug ticket instead of patching.

Where to send patches and pull requests

If you found this distribution on Github, sending a pull-request is the best way to contribute.

If a pull-request isn't possible, a bug ticket with a patch file is the next best option.

As a last resort, an email to the author(s) is acceptable.

Installing and using Dist::Zilla

Dist::Zilla is not required for contributing, but if you'd like to learn more, this section will get you up to speed.

Dist::Zilla is a very powerful authoring tool, optimized for maintaining a large number of distributions with a high degree of automation, but it has a large dependency chain, a bit of a learning curve and requires a number of author-specific plugins.

To install it from CPAN, I recommend one of the following approaches for the quickest installation:

# using CPAN.pm, but bypassing non-functional pod tests
$ cpan TAP::Harness::Restricted
$ PERL_MM_USE_DEFAULT=1 HARNESS_CLASS=TAP::Harness::Restricted cpan Dist::Zilla

# using cpanm, bypassing *all* tests
$ cpanm -n Dist::Zilla

In either case, it's probably going to take about 10 minutes. Go for a walk, go get a cup of your favorite beverage, take a bathroom break, or whatever. When you get back, Dist::Zilla should be ready for you.

Then you need to install any plugins specific to this distribution:

$ cpan `dzil authordeps`
$ dzil authordeps | cpanm

Once installed, here are some dzil commands you might try:

$ dzil build
$ dzil test
$ dzil xtest

You can learn more about Dist::Zilla at http://dzil.org/

path-tiny's Issues

Should there be an option for faster, "unsafe" operations?

I think safe is a good default, busing flocking and/or atomic writes is slow.

Give a faster unsafe option? Or is that not TIny?

Could remove on NFS be a problem?

Can we trust return value from unlink on NFS volumes? There are issues with unlinking open files, but I'm not sure how it affects us.

Should we check ! -e $path rather than just trust unlink return value?

Confusion how to do path comparisons

This is less a "bug" and more something I don't understand how to do properly yet with Path::Tiny.

I have no idea how/where such a problem would be documented.

Is there a recommended way to perform path comparisons sanely?

For instance, I want to provide a list of paths from say, File::HomeDir, and to stop traversal if a dir I see matches any of the ones provided by File::HomeDir, just the question is, how do I compare a string ( which may or may not have a volume part ) with a Path::Tiny in a reliable way?

I was thinking along the lines of

( $path->dirname .q[/] . $path->basename ) eq $somestring

Or something like that, but I don't know if I should be comparing $volume or not.

I don't even know if

$path->stringify eq $somestring

Is safe, or if I should be doing

$path->absolute->realpath eq $somestring

And it gets even more confusing if I ask for a path object instead of a $somestring, because I may need to compare the un-realpath and realpath both of each or something like that.

I guess this may be a similar request to the Path::Class style "subsumes" method, but I'm not really asking for subsumption, I'm just asking how to know if 2 paths of some description do in fact reference the same path somehow.

with Unicode::UTF8, split lines using lookbehind

@chansen suggested branching and splitting like split /(?<=\n)/ when not chomping

Path-Tiny-0.028 Path::Tiny on win32 turns C:/ or C:\ into C: but those aren't equivalent

http://perlmonks.org/?node_id=1049892 # Path-Tiny-0.028 Path::Tiny on win32 turns C:/ or C:\ into C: / absolute / realpath are broken

Editing sub path to comment out the following line seems to fix it :)

$path =~ s{/$}{} if $path ne "/"; # hack to make splitpath give us a basename

How to handle "could not map to Unicode" warnings?

Options:

• fatalize them
• leave them alone
• catch them in a __WARN__ handler and ignore them

If we're trying to read UTF-8 and the file isn't UTF-8, the "correct" thing to do might be to throw an error instead of allowing it through. Both :utf8 and :encoding(UTF-8) can have the "utf8" category fatalized, but that might be too restrictive if the warning occurs in common cases when the substitution character would be put in.

The other extreme is to catch warnings and ignore, since users are getting exactly what they asked for and it's not our fault if that's not right. We can turn off utf8 warnings for :utf8, but it's not respected by encoding(UTF-8) so we would need a __WARN__ handler.

Since I don't know the right answer, I'll do nothing for now but leave this as a placeholder.

output functions should accept an array reference

They should take scalar, list, or arrayref. See Path::Class::File for example.

Drop autodie dependency

We're only using autodie for exception objects. We can do without and that drops autodie dependency that prevents us from getting compatible back to 5.8.1.

No flock on Debian/kBSD (FreeBSD)

On Debian 7.1 GNU/kFreeBSD 9.0-2-amd64:
Error flock (LOCK_SH) on '...': Operation not supported at ...

Suggestion:
Two conditions in the if in sub _throw evaluate to false.

1. $IS_BSD:
   BEGIN { $IS_BSD = $^O eq 'openbsd' || $^O eq 'freebsd' }
   ->
   BEGIN { $IS_BSD = $^O eq 'openbsd' || $^O eq 'freebsd' || $^O eq 'gnukfreebsd' }
   because:
   $ perl -E 'say $^O'
   gnukfreebsd
2. $function eq 'flock'
   $function eq 'flock'
   ->
   $function =~ /^flock/
   because: $function is "flock (LOCK_SH)"

Separate "remove a file" from "remove a directory tree".

remove() is a bit too powerful.

$file->remove;

What if $file was actually a directory? Oh dear.

While its nice to have a "whatever it is, get rid of it" method, its rather rare one needs it. The main one should separate the concepts of removing a single thing and removing a tree of things both because they are different concepts and for safety. Most commonly one knows if they want to delete a file or a directory tree and its an error if the wrong thing shows up.

There should be remove_file (equivalent to rm), remove_dir (rmdir) and remove_tree (rm -rf) with perhaps a remove_any method.

remove, because its not clear from the name what its behavior is and people will reach for it without thinking, should be removed.

Remove autodie, use autodie::exception directly.

autodie is the biggest startup (and probably runtime) cost of Path::Tiny. It has to build wrappers around every system function and then every system call goes through those wrappers.

Instead, Path::Tiny could take the developer hit of coding its own "or die" statements and throw autodie::exception objects. From the user's perspective, nothing changes. In fact it gets better as we can have finer grained control over the exceptions which get thrown and the information in them.

But it adds a bunch of code and work for us.

Add subsumes & contains methods a la Path::Class

I've found the subsumes and contains methods of Path::Class to be handy. It'd be nice if Path::Tiny copied them.

Add locking to filehandle creation

Many modules take a filehandle for input or output (e.g. IO::Compress::Gzip) and they don't bother locking. We should make it easy to produce locked handles from filehandle.

$path->filehandle({ mode => ">", binmode => ":utf8", lock_ex => 1})

or

$path->filehandle( $mode, $binmode, $locked );

Or something along those lines. In the latter case we can guess LOCK_EX or LOCK_SH based on the $mode.

Documentation needs to be clearer about dealing with WIn32 for Unix people

There's very little documentation about Win32 related things, there's a reference to C: at the top in ->new(), but not much else.

For instance, one question I have which the docs don't answer, is how to determine if we've reached a "top level" directory of some kind, to which ->parent may return the node itself.

For instance, back when File::ShareDir::ProjectDistDir used Path::Class, this code was used , I was using the number of path components to determine up-level-ability, which proved not to work on Win32, so the code was adjusted to invoke File::Spec->os_root .

kentnl/File-ShareDir-ProjectDistDir@e18446e#diff-2303af8623c5e310198de9da53664452R218

This was however, obviously a bad option, because of the multiple volumes Win32 supports, meaning my code I use today that uses that same logic with Path::Tiny is broken on Win32 when the starting partition is D:/

kentnl/Path-FindDev#2

The reporter suggests using dirname should be adequate, I just don't know what values of dirname are really expected on Win32, because thats entirely undocumented.

My toying on linux is entirely pointless, because

$ perl -MPath::Tiny=path -E 'say path(q[D:\\foo])->parent'
# D:
$ perl -MPath::Tiny=path -E 'say path(q[D:\\foo])->parent->parent'
# .
$ perl -MPath::Tiny=path -E 'say path(q[D:/foo])->parent->absolute'
/home/kent/perl/Path-FindDev/D:

😕

Anyway, a bit of source diving suggests testing for dirname eq q[/] is safe to do here, just it would be helpful if the documentation gave a more obvious indication what path('C:/')->dirname returns. ( Also, what path(C:)->dirname returns, because its unix equivalent I'd imagine is path('')->dirname is forbidden )

Should croak on failure for functions that autodie doesn't catch

For example, the File::Path functions just return number of directories created/removed and have a funky way of hooking/catching errors. Path::Tiny should implement that hook and croak.

In addition to File::Path, there are calls to File::Spec, File::stat, File::Temp, Cwd, and Unicode::UTF8.

Note that copy already croaks on failure.

Build fails on fresh Ubuntu 12.04 LTS

Manifying blib/man3/Path::Tiny.3pm
DAGOLDEN/Path-Tiny-0.003.tar.gz
/usr/bin/make -- OK
'YAML' not installed, will not store persistent state
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-compile.t .... ok
t/basic.t ......... ok
t/children.t ...... ok
t/filesystem.t .... 1/?

Failed test 'copy throws error if permission denied'

at t/filesystem.t line 211.

Looks like you failed 1 test of 69.

t/filesystem.t .... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/69 subtests
t/input_output.t .. ok
t/mkpath.t ........ ok
t/normalize.t ..... ok
t/overloading.t ... ok
t/parent.t ........ ok
t/rel-abs.t ....... ok
t/temp.t .......... ok
t/zzz-spec.t ...... ok

Test Summary Report

t/filesystem.t (Wstat: 256 Tests: 69 Failed: 1)
Failed test: 68
Non-zero exit status: 1
Files=12, Tests=219, 1 wallclock secs ( 0.06 usr 0.01 sys + 0.96 cusr 0.10 csys = 1.13 CPU)
Result: FAIL
Failed 1/12 test programs. 1/219 subtests failed.
make: *** [test_dynamic] Error 255
DAGOLDEN/Path-Tiny-0.003.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports DAGOLDEN/Path-Tiny-0.003.tar.gz
Running make install
make test had returned bad status, won't install without force

Try to use open.pm hints from caller

For functions that open handles, see if we can respect the lexical open.pm hints from the caller.

Should chomp in lines() chomp CR?LF instead of just $/

I suspect that chomping any line terminators would be what people expect.

Digest::SHA dependency

It looks to me like this could be a "runtime recommends" dependency rather than "runtime requires".

There is one test case (digest.t) that makes use of the Digest::SHA functionality. This test case could be skipped if it's not available, or Digest::SHA could be additionally listed as a "test requires" dependency.

lines( { count => 3 } ) pads return with undefs

If I call lines( { count => 3 } ) on a file that only has 2 lines I get a 3-element list with the last being undef. I am not sure if this is the planned behaviour (though I think I'd prefer it wasn't :) ...

In any case I have not seen it documented nor tested.

Should mkpath be renamed?

It doesn't follow same naming pattern as other methods.

It echoes File::Path, but should really be "make_path" for consistency with "remove_tree".

Possibly, it should be "make_tree" for proper parallelism.

spew against a symlink will atomically replace symlink, not target file

Because spew works by spewing to a temp file and then does atomic rename to the target, an existing symlink will be replaced with a file.

If a spew target exists and is a link, we probably need to follow the link and atomically replace the destination instead.

TEMPLATE named argument is ignored when passed to Path::Tiny->tempdir

According to the POD for Path::Tiny->tempdir, you must use the TEMPLATE named argument if you want to use a template. In my usage, however, the template is being ignored.

I wasn't sure what style of test you wanted for this, so I didn't just provide a patch. I can do so if you wish, however.

User friendly chmod?

Consider if we can provide a friendlier chmod using more familiar unix letter codes like "go-w".

On the other hand, Casey West's implementation for ppt is nowhere near Tiny enough: https://metacpan.org/source/CWEST/ppt-0.14/html/commands/chmod/SymbolicMode.pm

File::chmod is also rather verbose.

Metaissue: Path::Tiny is not very tiny

Path::Tiny uses quite a large number of non-core dependencies, especially in the testing phase.

http://deps.cpantesters.org/?module=Path::Tiny

Spew doesn't work on NFS

This may be by design, but spewing on a NFS mounted FS fails (on FreeBSD) with: "Can't lock filehandle for exclusive access: Operation not supported". It is

flock( $fh, Fcntl::LOCK_EX() ) or _throw( 'flock', [ $fh, Fcntl::LOCK_EX() ] );

in spew() which fails.

Is there someway of this or is the solution just to avoid spewing on NFS? File::Slurp avoids this by moving the file instead of locking. Not sure if that is better (I'm not sure that move is atomic on NFS)...

lines_utf8({chomp=>1}) dies

#!/usr/bin/env perl

use 5.014;
use strict;
use warnings;
use Path::Tiny;

my $p = path($0);
say scalar $p->lines();
say scalar $p->lines_utf8();
say scalar $p->lines({chomp=>1});
say scalar $p->lines_utf8({chomp=>1});

Output:

12
12
12
Can't call method "filehandle" on an undefined value at /opt/perl-5.16/lib/site_perl/5.16.2/Path/Tiny.pm line 486.

This is Path::Tiny version 0.020 on Perl 5.16.2.

Test failure on AIX, perl 5.18.1

(Note that the perl being used is not yet installed, but I doubt that is relevant to this problem)

$ perl -Mblib t/locking.t
    ok 1 - Got a tempfile
    ok 2 - Opened file for writing with lock
    ok 3 - opened again for reading
    not ok 4 - read lock not available
    #   Failed test 'read lock not available'
    #   at t/locking.t line 33.
    1..4
    # Looks like you failed 1 test of 4.
not ok 1 - write locks blocks read lock
#   Failed test 'write locks blocks read lock'
#   at t/locking.t line 34.
1..1
# Looks like you failed 1 test of 1.

$ oslevel
7.1.0.0

When I go with the debugger, I get:

  DB<5> x $!
0  'A specified file does not support the ioctl system call.'
  DB<6> x 0+$!
0  25

This may be related to the BSD issue that causes this test file to already skip.

Win32 terminates _DURING_ fork

This is a follow up from kentnl/File-ShareDir-ProjectDistDir#10

Seems Path::Tiny use of require threads inside CLONE causes Perl to die with

This application has requested the Runtime to terminate it in an unusual way.

It may be a core bug.

However, symptoms are that a debug perl gives this backtrace:

>   kernel32.dll!_ExitProcess@4()   
    msvcr71.dll!__crtExitProcess(int status=0x7c3638c5)  Line 463 + 0x9 C
    00000003()  
    msvcr71.dll!doexit(int code=0xffffffff, int quick=0x0006f430, int retcaller=0x7c36ad81)  Line 414 + 0x7 C
    msvcr71.dll!__crtExitProcess(int status=0x0006f430)  Line 463 + 0x9 C
    ffffffff()  
    msvcr71.dll!_exit(int code=0x00000003)  Line 311 + 0xd  C
    msvcr71.dll!raise(int signum=0x00000016)  Line 508  C
    msvcr71.dll!abort()  Line 48 + 0x7  C
    perl512.dll!win32_checkTLS(interpreter * host_perl=0xbaadf00d)  Line 64 C++
    perl512.dll!CheckInterp(CPerlHost * host=0x002862e8)  Line 238 + 0xf    C++
    perl512.dll!IPerlDir2Host(IPerlDir * piPerl=0x0028647c)  Line 278 + 0xe C++
    perl512.dll!PerlDirMapPathA(IPerlDir * piPerl=0x0028647c, const char * path=0x0125298c)  Line 1192 + 0xd    C++
    perl512.dll!win32_stat(const char * path=0x0125298c, _stati64 * sbuf=0x0006f630)  Line 1474 + 0x1a  C
    perl512.dll!PerlLIONameStat(IPerlLIO * piPerl=0x00286414, const char * path=0x0125298c, _stati64 * buffer=0x0006f630)  Line 1067 + 0xd  C++
    perl512.dll!S_doopen_pm(interpreter * my_perl=0x00e50b7c, const char * name=0x01252934, const unsigned int namelen=0x0000001e)  Line 3239 + 0x1e    C
    perl512.dll!Perl_pp_require(interpreter * my_perl=0x00e50b7c)  Line 3580 + 0x16 C
    perl512.dll!Perl_runops_debug(interpreter * my_perl=0x00e50b7c)  Line 2049 + 0xd    C
    perl512.dll!Perl_call_sv(interpreter * my_perl=0x00e50b7c, sv * sv=0x01031d5c, volatile long flags=0x00000006)  Line 2590 + 0x36    C
    perl512.dll!perl_clone_using(interpreter * proto_perl=0x00394014, unsigned long flags=0x00000001, IPerlMem * ipM=0x002862ec, IPerlMem * ipMS=0x00286308, IPerlMem * ipMP=0x00286324, IPerlEnv * ipE=0x00286340, IPerlStdIO * ipStd=0x00286378, IPerlLIO * ipLIO=0x00286414, IPerlDir * ipD=0x0028647c, IPerlSock * ipS=0x002864a8, IPerlProc * ipP=0x00286558)  Line 12550 + 0x15   C
    perl512.dll!PerlProcFork(IPerlProc * piPerl=0x00285bf8)  Line 1859 + 0x65   C++
    perl512.dll!Perl_pp_fork(interpreter * my_perl=0x00394014)  Line 4082 + 0x16    C
    perl512.dll!Perl_runops_debug(interpreter * my_perl=0x00394014)  Line 2049 + 0xd    C
    perl512.dll!S_run_body(interpreter * my_perl=0x00394014, long oldscope=0x00000001)  Line 2308 + 0xd C
    perl512.dll!perl_run(interpreter * my_perl=0x00394014)  Line 2233 + 0xd C
    perl512.dll!RunPerl(int argc=0x00000002, char * * argv=0x00282510, char * * env=0x00282790)  Line 270 + 0x9 C++
    perl.exe!main(int argc=0x00000002, char * * argv=0x00282510, char * * env=0x00282cc0)  Line 23 + 0x12   C
    perl.exe!mainCRTStartup()  Line 398 + 0xe   C
    kernel32.dll!_BaseProcessStart@4()  + 0x23

And the trigger appears to be

https://metacpan.org/source/DAGOLDEN/Path-Tiny-0.048/lib/Path/Tiny.pm#L39

sub CLONE { require threads; $TID = threads->tid }

Experimentally, we discovered manually calling

require threads;

Somewhere before forking served as a workaround.

So perhaps the perl interpreter just doesn't like doing require inside CLONE on Win32

I'm just nailing this bug here so it doesn't get lost while our hero @bulk88 determines if its something that needs to be fixed in blead etc.

Path::Tiny->new() and path() are not equivalent, yet the POD says they are.

The POD says that new is just path with method invocation overhead.

That doesn' t seem to be true, to wit:

use Path::Tiny;

use Test::More;

my $a = Path::Tiny->new('a');
my $b = Path::Tiny->new('b');

my $c = Path::Tiny->new($a, $b);

my $d = path($a, $b);

ok($c eq $d, "paths match");

done_testing;

Not sure whether to fix the POD to match what the code's doing or to fix new so that it consumes the rest of @_.

path() with no arguments or undef, or empty string should be a failure

Any variation of path(), path('') or path(undef) should be a fatal error. The idea that they might return cwd is very clever but it is also very clever.

As pointed out by @myfwhite, accepting undef or empty string as a valid argument leads to very dangerous situations like so:

my $path = something_that_returns_a_string_path;
path($path)->remove;  # oh dear    

For precedence, this feature was deprecated in chdir for exactly the same reasons. http://perl5.git.perl.org/perl.git/commit/35ae6b54cb5a8d6a9ce74c7f818c7d62df4ac621

While one might argue that path() could be safely retained, but its really not worth the extra code, docs, tests and conflating two pieces of functionality. Instead, Path::Class->cwd should be added which can be made simpler, faster and easier to find (for example, if you search for cwd or current working directory in the docs you don't come up with path()).

Happy to do the patching.

idea for enhancement: encodings for filenames

1. allow to specify encodings for filenames in filesystem (including UTF-8).
2. this is useful even if encoding is UTF-8 - it would fixes problem working with downgraded vs upgraded Latin1: http://perldoc.perl.org/perlunicode.html "When Unicode Does Not Happen"

autodie and Mojolicious

I just wanted to add this cryptic message when using Path::Tiny which uses autodie in a Mojolicious application.

Couldn't load application from file "script/test_path_tiny": autodie version 2.14 required--this is only version 2.13 at script/test_path_tiny line 5.
BEGIN failed--compilation aborted at script/test_path_tiny line 5.

autodie is already latest. I tried also going back to autodie 2.14 (same problem)

$ cpanm autodie
autodie is up to date. (2.16)

The funny thing is that it only happens under morbo script/test_path_tiny

Feature request: children($glob_pattern)

Would it be possible to give children() an optional parameter, which is used as a glob pattern, so that $dir->children('*.txt') returns all .txt files in the directory?

Add comment in spew() code

The spew method has the following line:

    $binmode = ( ( caller(0) )[10] || {} )->{'open>'} unless defined $binmode;

It would be helpful to add a comment above the line to explain what it does.

Have parent() take an argument for number of directories upwards

In a blog comment, Steffen Winkler suggests $path->parent($n).

He references rt#76493 on Path::Class as an example.

lines() in scalar context returns first line, not number of lines

According to the documentation:

Because the return is a list, lines in scalar context will return the number of lines (and throw away the data).

In reality, though, it returns the first line:

% perl -MPath::Tiny -E 'say scalar path("~/.profile")->lines;'
# ~/.profile: executed by the command interpreter for login shells.

Should slurp_utf8, etc, set :crlf on Win32?

How many people on windows use ":utf8:crlf" anyway? Does anyone care?

atomic writing is unsafe

the temporary files used for atomic writes should be opened via sysopen with an exclusive flag.

Feature Request: Methods to get Digest::MD5 and Digest::SHA objects from a path

I would love to do this:

my $sha256 = path('foo.txt')->sha256;
my $md5 = path('foo.txt')->md5;

threads.pm should not be listed as a PREREQ_PM for non-threaded perls

If threads.pm is listed as a prerequisite, and the Path::Tiny testsuite fails, then CPAN::Reporter refuses to send the fail report because it thinks that some of the prerequisites failed. The final CPAN::Reporter report looks like this:

CPAN::Reporter: test results were not valid, Prerequisite version too low:
requires:                  

    Module                Need Have   
    --------------------- ---- -------
[...]
  ! threads               0    broken 
[...]

Don't know what's the best approach to test for a threaded perl, maybe check $Config{usethreads} eq 'define'

unexpected warning: Use of -l on filehandle at .../Path/Tiny.pm line 291.

I'm not exactly sure when I started seeing this, but perldiag says the following:

   Use of -l on filehandle %s
       (W io) A filehandle represents an opened file, and when you opened
       the file it already went past any symlink you are presumably trying
       to look for.  The operation returned "undef".  Use a filename
       instead.

Although the code appears to be doing a "-l" on a dirhandle (not a filehandle), presumably to the same effect. My versions:

$ pmvers Path::Tiny
0.018

$ perl -v

This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux

Implement new move/copy/rename interface

Following discussions in #22 I sketched out a plan to significantly revise how move/copy/rename work. This issue is a placeholder to remind me to finish that work.

tempfiles are unsafe

We open a tempfile and then close the handle, which avoids some issues on Win32 but means we lose the protection of the exclusive open.

tempfile needs to do something better. Possibly, keep the handle open and provide it (suitably modified) from filehandle(). This might still be a problem if someone wants to separately open by filename because we'll be keeping a cached open handle.

Or, just let it create the temporary file name without opening anything and add an "exclusive" option to filehandle and spew/append functions to do the right sysopen when needed. This won't necessarily be as safe as File::Temp (with all its extra checks), but might be sufficient for casual use.

Now that we have a recursive iterator, how about a visitor?

Instead of this:

my $next = $path->iterator({recurse => 1});
while ( my $file = $next->() ) {
    process_file($file);
}

How about this:

$path->visit(\&process_file, {recurse => 1});

It's trivial to code and would be fairly useful for someone who doesn't need/want to deal with a file iterator like File::Next or Path::Iterator::Rule

Use PerlIO::utf8_strict if available

if installed, favor it over :encoding(UTF-8)

`remove` should return false if the thing did not exist

remove currently returns true when the thing its removing doesn't exist. This is lying to the user and makes the return value less useful. A true return value now means "the file no longer exists" but not "I successfully removed a file".

While the former might seem useful, it is not because of exceptions. There is no way for remove to return a false value. If unlink returns false, it throws an exception. If remove does not throw an exception then you know either 1) the thing did not exist in the first place or 2) deleting it was successful.

So its better to use the return value to say if anything was actually deleted.

Cleanup of paths with respect to physical filesystem?

This is a placeholder for the irc conversation we just had about whether something would make sense which did something like path(Cwd::realpath($self)), either in ->absolute or as a separate method.

Errors are from inside Path::Tiny

Path::Tiny uses autodie, awesome. Unfortunately the error messages are located inside Path::Tiny.

$ perl -wle 'use Path::Tiny;  path("/foo/bar")->openr'
Can't open '/foo/bar' for reading: 'No such file or directory' at /Users/schwern/perl5/perlbrew/perls/perl-5.16.2-threads/lib/site_perl/5.16.2/Path/Tiny.pm line 200

I'm not sure how to convince autodie that its inside a wrapper method. I've asked them. https://github.com/pfenwick/autodie/issues/15

Can tempfile and tempdir become @EXPORT_OK?

Would it be possible to add tempfile and tempdir (and perhaps, for consistency's sake, also cwd and rootdir) to @EXPORT_OK? People who'd like to import those functions can then do so, without affecting those who don't.