in reply to Okay, I know why is it failing
in thread This regular expression has me stumped

Solved! 
use strict;
use warnings;
my $file;

foreach $file (@ARGV) {
    open (INFILE,"<$file") or die "Cannot open Input file\n";

    while (<INFILE>) {
        s!(?:^|\w*/|\.\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!
+$1!g;
#        s!\.\.!!g;
        print "$_";
    }
    close INFILE;
}

[download]

Replies are listed 'Best First'.
Re^2: Okay, I know why is it failing
by tachyon-II (Chaplain) on May 02, 2008 at 09:34 UTC

    Hmm, so that's better than a split/grep/map solution? Why try to do something with one very complicated regex (well you use two) when breaking the task down into small chunks can make it easy to do, easy to understand, easy to debug, easy to maintain.....

[reply]
      I can try the split method too. But I am not sure whether the split map method will do all corner cases. This time I just worked with the regexp because believe it or not, I am more comfortable with regexps!
[reply]

        This is a regex solution, just a simplified one!

        Almost all parsing can be looked at as:

        1. Get records (in this case a line)
        2. Tokenise records (in this case split on whitespace)
        3. Examine tokens (in this case the grep that ignores any token without a file delimiter / in it)
        4. Extract data from the tokens (the simple RE in the map)

        The only edge cases that will be missed are ones for which there is probably no robust solution. These are:

        1. A filename without a filepath. But this is just a word token and is only identifiable if you know all the possible tokens or you can rely on say file.format syntax.
        2. Filenames that can contain the same random \W tokens at the end of the filepath ie Perl::Module:@ which is possible although unlikely
        3. Fielnames that contain newlines (we won't get proper records) - unsolvable and also improbable
        4. Dates like 2/8/2008 which will look like a filepath. If these occur they are likely to be in the first token which we can ignore because we know this will always be the logdate.

        The thing with a multistage parse is that it is transparent. Because each stage only does a little thing debugging is likely to be far easier and less (un)likely to break the downstream parts.

        Cheers

        tachyon

[reply]

In Section Seekers of Perl Wisdom