[tpm] splitting filespecs

Stuart Watt stuart at morungos.com
Thu May 10 11:28:33 PDT 2012


OK, I see the issue, but you still can (should?)  handle this with File::Spec. If you assume that these special cases (and there are only two) are always to be interpreted as a directory (I think that's really the problem), then something like the following will do it:

my ($vol, $dir, $file) = File::Spec->splitpath($value, ($value eq File::Spec->updir() or $value eq File::Spec->curdir()))

This will split forcing no file => 1 for . and .., and not for anything else. You could then maybe merge as before. This is also Windows-safe, and is actually logically correct for all platforms, as you are merely saying that if the string passed matches the exact string for the current directory or the parent directory, assume it is a directory. 

I used to use Lisp which had proper rules for merging pathnames that encapsulated some of this, but I just checked and as far as I can see, it also gets it wrong in these cases. I actually believe there is a case for a CPAN module which embeds this merging logic, i.e., takes two filenames and merges them, *not* a rel2abs, but a fill-in-the-blanks, which is very subtly different, and extremely handy for defaulting. The Lisp version also did file types, and this was also very handy. 

--S


On 2012-05-10, at 1:57 PM, Fulko Hew wrote:

> 
> 
> On Thu, May 10, 2012 at 1:30 PM, <rob at cryptic.org> wrote:
> Further to that, "." actually is a special-case directory, similar to "..". Like a double period is "parent directory", a single period is "current directory". It's like this on both Unix and Windows (and presumably Mac).
> 
> Actually its both a special case filename and a directory.
> My trouble is that as far as File::Spec is concerned '.' and '..' are returned as the filename
> ... which is technically correct, BUT if thats all that was provided,
> it really means 'this' or 'the parent' directory [not a filename]
> 
> As a result, I'd think the directory wasn't provided and substitute my own, and use the
> filename provided and end up with "/defdir/."
> ... which would be _completely_ wrong.
> 
> If someone gave me '.' as their 'target'  you'd want to interpret that as
> "they want it to be in the 'default' file in _this current_ directory" ie.  ./deffile
> 
> 
> So in either case... these libraries still don't do it correctly (for my needs)
> 
> I've ended up using a combo of special case tests for '.' and '..'
> [meaning this (or parent directory) with no filename provided];
> otherwise use File::Basename to extract the filename and
> extract any stuff in front of the filename as the directory path
>    (and ignore what File::Basename provides)
> and then finally apply my default path (if the prefix/dirpath was empty)
> and default filename (if filename was empty)
> and then splice them back together again using File::Spec::catfile()
> 
> 
> 
> 
> _______________________________________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/listinfo/toronto-pm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20120510/c8a798c1/attachment.html>


More information about the toronto-pm mailing list