in reply to Re: Piping many individual files into a single perl script
in thread Piping many individual files into a single perl script

I personally believe that as a very minor side note, since the OP mentions something like "10000 files," some shells do have problem with a large amount of files. Except that I can't remember how large is large. But I have seen error messages for something like "command line too long" occasionally. In that case, adopting the same technique as for Windows, would be a cure...

use File::Glob qw( bsd_glob );
@ARGV = map bsd_glob($_), @ARGV;

[download]

This sounds very wrong [Update: but it is right, see my reply to ikegami's comment] unless one has a good reason to do so: since we're on Windows, we most probably want DOS/Windows-like globbing and glob is dwimmy enough to select its own correct "incarnation:" in all of my scripts that may want globbing, written for Windows or "ported" (what a big word!) there from *NIX, I include the same code as BrowserUk's. Sometimes, (depending on how "important" the app will be...) I also provide "standard" -i and -o cli switches for input and output, since shell redirection has some very little but not null deficiencies.

--
If you can't understand the incipit, then please check the IPB Campaign.

Replies are listed 'Best First'.
Re^3: Piping many individual files into a single perl script
by ikegami (Patriarch) on Sep 29, 2008 at 14:07 UTC

    I include the same code as BrowserUk's

    But that uses bsd_glob as well. And worse yet, a version that breaks when a space is present.

[reply]

      Upon reading the documentation for File::Glob I was about to say that I stand corrected, but to be precise, I actually wrote that "This sounds very wrong" (with additional emphasis added now) so I won't, because I still claim that it sounds very wrong. That the actual globbing function's name is bsd_glob() behind the scenes is a matter of fact, but using it explicitly conveys the psychological feeling of resorting to a bsd thingie, whatever it is. The rationale is that perl's glob will dwimmily do whatever is best for the OS one is running under: of course, I acknowledge that there's some sloppiness in this claim since

      • even under *NIX different shells may perform different globbing - I'm not really sure: is there any baseline defined by POSIX?
      • under Windows, it's not defined at all, being left to each individual application: in that case I think that the "standard" behaviour could be defined by that of cli utilities that come with the OS itself...

      Whatever, if e.g. glob() breaks when a space is present, I would still regard it as a feature: provided that does it conform to the standard behaviour on the given OS. Failure to do so would be definitely considered a bug instead.

      --
      If you can't understand the incipit, then please check the IPB Campaign.
[reply]
[d/l]
[select]

        provided that does it conform to the standard behaviour on the given OS.

        Perl's glob is platform independent. It behaves the same on all platforms.

        if e.g. glob() breaks when a space is present

        It's done that way to allow glob('*.h *.c'), but I called it broken since patterns are usually already separated into multiple calls to glob. bsd_glob is identical to glob except for the difference in the treatment of spaces.

        under Windows, it's not defined at all, being left to each individual application

        They usually delegate to the FindFirstFile system call. Perl has File::DosGlob which resembles FindFirstFile.

[reply]
[d/l]
[select]
Re^3: Piping many individual files into a single perl script
by Anonymous Monk on Sep 29, 2008 at 14:11 UTC
    Its not exactly files, its characters :) for example, WinXP its 8191, Win2k/NT4 its 2047
[reply]

In Section Seekers of Perl Wisdom