Re: Any way to simulate a Windows path handling for File::Spec without Windows?

[davido]

This isn't the point to your post but I wanted to mention a possible bug I noticed:

my ($new_string, $longest_string) = '';

This probably ought to be my ($new_string, $longest_string) = ('','');, because later you're using $longest_string as a pattern with the s/$longest_string// construct. But being undefined is the least of your worries:

#!usr/bin/env perl

use strict;
use warnings;

use File::Temp qw(tempdir);
use File::Spec::Functions qw(catfile);

my $dir = tempdir('pmtest_XXXXX', TMPDIR => 1, CLEANUP => 1);

my $test_filename = '{a}';
my $full_path = catfile($dir, $test_filename);

open my $fh, '>', $full_path or die "Cannot create $full_path: $!\n";
print $fh "Hello world.\n";
close $fh;

print "We created $full_path as a file.\n"
    if -e $full_path && -f _;

my $target = "$full_path.extra";

$target =~ s/$full_path//;

...produces...

We created /tmp/pmtest_hmfIn/{a} as a file.
Unescaped left brace in regex is passed through in regex; marked by <-
+- HERE in m//tmp/pmtest_hmfIn/{ <-- HERE a}/ at mytest.pl line 23.

If you use a part of a path as a regular expression pattern that pattern has all the semantics of a regular expression pattern. You probably want to use quotemeta or \Q, to play it a little safer. Otherwise, you're exposing the regex engine to user input, which should be considered hostile. One could create a path that results in a pattern that either fails to parse, or that parses but has abysmal performance.

[nysus]

Thanks, yeah, I caught the regex bug and fixed it in a release earlier today. Thanks for the not on multiple assignment. I'll fix that up.