File-Find skips directories with spaces depending on path separator on Windows

Discussion in 'Perl Misc' started by Matt Garrish, Jan 15, 2006.

  1. Matt Garrish

    Matt Garrish Guest

    After making a rather juvenile over-simplification in a previous thread, I
    wrote a script out of pure curiosity to see how many extensionless files I
    could find on my c:\ drive. I wrote the following simple code to do this:

    ### code start

    use File::Find;

    my ($ext, $noext);

    find(\&wanted, 'c:/');

    print "Files with extensions: $ext\nFiles without extensions: $noext\n";

    sub wanted {

    return if -d $File::Find::name;

    ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext += 1;

    }

    ### code end

    Which gave me the following obviously inaccurate results:

    Files with extensions: 4811
    Files without extensions: 236

    I printed the filenames as it went and noticed quickly that it was skipping
    all directories with spaces in the path (\program files\, etc.). I then
    changed the invokation to the following:

    find(\&wanted, 'c:\\');

    And instead got the following

    Files with extensions: 66954
    Files without extensions: 1522

    Is this a bug in File::Find? Or am I making an incorrect assumption about
    how it works?

    Matt
    Matt Garrish, Jan 15, 2006
    #1
    1. Advertising

  2. Matt Garrish

    MSG Guest

    Matt Garrish wrote:
    > find(\&wanted, 'c:/');
    >
    > I printed the filenames as it went and noticed quickly that it was skipping
    > all directories with spaces in the path (\program files\, etc.). I then
    > changed the invokation to the following:
    >
    > find(\&wanted, 'c:\\');
    >
    > Is this a bug in File::Find? Or am I making an incorrect assumption about
    > how it works?
    >
    > Matt


    I ran your code on my computer and switched around with the above two
    find statements,
    both gave me the same counts. White space or not isn't an issue
    MSG, Jan 15, 2006
    #2
    1. Advertising

  3. MSG wrote:
    > Matt Garrish wrote:
    > > find(\&wanted, 'c:/');
    > >
    > > I printed the filenames as it went and noticed quickly that it was skipping
    > > all directories with spaces in the path (\program files\, etc.). I then
    > > changed the invokation to the following:
    > >
    > > find(\&wanted, 'c:\\');
    > >
    > > Is this a bug in File::Find? Or am I making an incorrect assumption about
    > > how it works?
    > >
    > > Matt

    >
    > I ran your code on my computer and switched around with the above two
    > find statements,
    > both gave me the same counts. White space or not isn't an issue


    what version of Perl are you using?
    it_says_BALLS_on_your_forehead, Jan 15, 2006
    #3
  4. Matt Garrish

    Matt Garrish Guest

    "MSG" <> wrote in message
    news:...
    >
    > Matt Garrish wrote:
    >> find(\&wanted, 'c:/');
    >>
    >> I printed the filenames as it went and noticed quickly that it was
    >> skipping
    >> all directories with spaces in the path (\program files\, etc.). I then
    >> changed the invokation to the following:
    >>
    >> find(\&wanted, 'c:\\');
    >>
    >> Is this a bug in File::Find? Or am I making an incorrect assumption about
    >> how it works?
    >>

    >
    > I ran your code on my computer and switched around with the above two
    > find statements,
    > both gave me the same counts. White space or not isn't an issue
    >


    It's nice that you think that, but you'll excuse me for not finding your
    suggestion terribly conclusive. I could post the filename lists that show
    that it is exactly the reason for the discrepancy, but I don't imagine
    anyone wants to see them. The question again is why? I can believe that it
    might be a bug either in Perl, the module or the OS, which are as follows:
    ActivePerl 5.8.7 Build 815, File::Find v. 1.09 on XP Pro.

    Matt
    Matt Garrish, Jan 15, 2006
    #4
  5. Matt Garrish

    MSG Guest

    Matt Garrish wrote:
    > "MSG" <> wrote in message
    > news:...
    > >
    > > Matt Garrish wrote:
    > >> find(\&wanted, 'c:/');
    > >>
    > >> I printed the filenames as it went and noticed quickly that it was
    > >> skipping
    > >> all directories with spaces in the path (\program files\, etc.). I then
    > >> changed the invokation to the following:
    > >>
    > >> find(\&wanted, 'c:\\');
    > >>
    > >> Is this a bug in File::Find? Or am I making an incorrect assumption about
    > >> how it works?
    > >>

    > >
    > > I ran your code on my computer and switched around with the above two
    > > find statements,
    > > both gave me the same counts. White space or not isn't an issue
    > >

    >
    > It's nice that you think that, but you'll excuse me for not finding your
    > suggestion terribly conclusive. I could post the filename lists that show
    > that it is exactly the reason for the discrepancy, but I don't imagine
    > anyone wants to see them. The question again is why? I can believe that it
    > might be a bug either in Perl, the module or the OS, which are as follows:
    > ActivePerl 5.8.7 Build 815, File::Find v. 1.09 on XP Pro.
    >
    > Matt


    Sorry I need to make a correction:
    You are right in finding the discrepancy. I checked again and got
    different counts with
    'c:/' and 'c:\\'. Earlier I mistakenly ran them on 'c:/documents and
    settings' and 'c:\\documents and settings' and got the same counts. My
    bad.

    So that means file:find has some special treatment for root directory.
    I kind of recall
    reading it from somewhere...
    MSG, Jan 15, 2006
    #5
  6. Matt Garrish

    Matt Garrish Guest

    "MSG" <> wrote in message
    news:...
    >
    > Matt Garrish wrote:
    >> "MSG" <> wrote in message
    >> news:...
    >> >
    >> > Matt Garrish wrote:
    >> >> find(\&wanted, 'c:/');
    >> >>
    >> >> I printed the filenames as it went and noticed quickly that it was
    >> >> skipping
    >> >> all directories with spaces in the path (\program files\, etc.). I
    >> >> then
    >> >> changed the invokation to the following:
    >> >>
    >> >> find(\&wanted, 'c:\\');
    >> >>
    >> >> Is this a bug in File::Find? Or am I making an incorrect assumption
    >> >> about
    >> >> how it works?
    >> >>
    >> >
    >> > I ran your code on my computer and switched around with the above two
    >> > find statements,
    >> > both gave me the same counts. White space or not isn't an issue
    >> >

    >>
    >> It's nice that you think that, but you'll excuse me for not finding your
    >> suggestion terribly conclusive. I could post the filename lists that show
    >> that it is exactly the reason for the discrepancy, but I don't imagine
    >> anyone wants to see them. The question again is why? I can believe that
    >> it
    >> might be a bug either in Perl, the module or the OS, which are as
    >> follows:
    >> ActivePerl 5.8.7 Build 815, File::Find v. 1.09 on XP Pro.
    >>
    >> Matt

    >
    > Sorry I need to make a correction:
    > You are right in finding the discrepancy. I checked again and got
    > different counts with
    > 'c:/' and 'c:\\'. Earlier I mistakenly ran them on 'c:/documents and
    > settings' and 'c:\\documents and settings' and got the same counts. My
    > bad.
    >
    > So that means file:find has some special treatment for root directory.
    > I kind of recall
    > reading it from somewhere...
    >


    I'm not sure I believe that either. I can't see that the module would be
    written to incorrectly handle drive roots in Windows. It's certainly what it
    appears to be doing, but I would regard it more as a bug.

    Matt
    Matt Garrish, Jan 15, 2006
    #6
  7. Matt Garrish

    Matt Garrish Guest

    "Matt Garrish" <> wrote in message
    news:kolyf.25301$...
    >
    > "MSG" <> wrote in message
    > news:...
    >>
    >>
    >> Sorry I need to make a correction:
    >> You are right in finding the discrepancy. I checked again and got
    >> different counts with
    >> 'c:/' and 'c:\\'. Earlier I mistakenly ran them on 'c:/documents and
    >> settings' and 'c:\\documents and settings' and got the same counts. My
    >> bad.
    >>
    >> So that means file:find has some special treatment for root directory.
    >> I kind of recall
    >> reading it from somewhere...
    >>

    >
    > I'm not sure I believe that either. I can't see that the module would be
    > written to incorrectly handle drive roots in Windows. It's certainly what
    > it appears to be doing, but I would regard it more as a bug.
    >


    I've submitted a bug report...

    Matt
    Matt Garrish, Jan 15, 2006
    #7
  8. Matt Garrish

    MSG Guest

    Matt Garrish wrote:

    >
    > ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext += 1;


    There is a bug here in the above line:
    It has the same precedence as
    ( ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext ) += 1;
    ----^----------------------------------------------------------------------------^---------
    So your count in $ext always gets doubled as a result. A better one can
    be:
    ($File::Find::name =~ /\.\w+$/) ? $ext++ : $noext++ ;
    MSG, Jan 15, 2006
    #8
  9. Matt Garrish

    Anno Siegel Guest

    MSG <> wrote in comp.lang.perl.misc:
    >
    > Matt Garrish wrote:
    >
    > >
    > > ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext += 1;

    >
    > There is a bug here in the above line:
    > It has the same precedence as
    > ( ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext ) += 1;
    > ----^----------------------------------------------------------------------------^---------
    > So your count in $ext always gets doubled as a result. A better one can
    > be:
    > ($File::Find::name =~ /\.\w+$/) ? $ext++ : $noext++ ;


    The parentheses around the =~ operation are not needed. The ?: operator
    returns lvalues, so one could even write:

    ++ ( $File::Find::name =~ /\.\w+$/ ? $ext : $noext);

    Anno
    --
    If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers.
    Anno Siegel, Jan 17, 2006
    #9
  10. Matt Garrish

    Matt Garrish Guest

    "Anno Siegel" <-berlin.de> wrote in message
    news:dqipkd$l3h$-Berlin.DE...
    > MSG <> wrote in comp.lang.perl.misc:
    >>
    >> Matt Garrish wrote:
    >>
    >> >
    >> > ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext += 1;

    >>
    >> There is a bug here in the above line:
    >> It has the same precedence as
    >> ( ($File::Find::name =~ /\.\w+$/) ? $ext += 1 : $noext ) += 1;
    >> ----^----------------------------------------------------------------------------^---------
    >> So your count in $ext always gets doubled as a result. A better one can
    >> be:
    >> ($File::Find::name =~ /\.\w+$/) ? $ext++ : $noext++ ;

    >
    > The parentheses around the =~ operation are not needed. The ?: operator
    > returns lvalues, so one could even write:
    >
    > ++ ( $File::Find::name =~ /\.\w+$/ ? $ext : $noext);
    >


    Interesting. I'd never considered that (though, in my defense, wrapping the
    expression being evaluated is just a convention I've adopted regardless of
    the complexity or necessity to delimit the expression (boolean values
    aside); they're not there because I thought they were necessary).

    Matt
    Matt Garrish, Jan 17, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stephen Ferg
    Replies:
    30
    Views:
    934
    Andrew Dalke
    Sep 30, 2003
  2. Tony Meyer
    Replies:
    1
    Views:
    628
    Stephen Horne
    Sep 26, 2003
  3. Wanderer

    file find skips first letter

    Wanderer, Feb 15, 2011, in forum: Python
    Replies:
    4
    Views:
    293
  4. Harry
    Replies:
    0
    Views:
    98
    Harry
    Sep 14, 2004
  5. Justin Johnson

    Path Separator and Windows

    Justin Johnson, Dec 29, 2005, in forum: Ruby
    Replies:
    19
    Views:
    362
    Justin Johnson
    Dec 30, 2005
Loading...

Share This Page