in reply to Working with a unkown number of arrays

You've gone about this problem in a somewhat ugly manner (it appears as if you cut and pasted the same code 3 times). A more elegant solution would store everything in a hash with the priority level included. So each priority value would be a key and file (or directory) would be a value (or vice versa). Then you could just sort by hash key/value. Pseudo-code:
sub Prioritise_requests { my ($input_directory, $node) = @_; my %files; $files{1} = $input_directory."1"; $files{2} = $input_directory."2"; $files{3} = $input_directory,"3"; # this is looping on the directories in a prioritized manner foreach (sort keys %files) { open(*DATA,$_) or die; # this is looping through each file you want in each directory foreach (sort grep(/^Flat_file.*\.txt$/,readdir(DATA))) { # do your stuff for each file } close(DATA); } }

Replies are listed 'Best First'.
Re^2: Working with a unkown number of arrays
by polettix (Vicar) on Feb 05, 2007 at 19:28 UTC
    Hi, I understand that what you wrote is marked as "pseudocode", but I noticed a couple of strange things:
    $files{3} = $input_directory,"3";
    Maybe you meant to put a dot "." instead of a comma ","?

    Another thing that I don't understand from this fragment is if %files holds filenames or directory names. The use of open() and close() seems to point to "filenames", but in this case the readdir(DATA) should be simply <DATA>.

    Regarding the open(), at the price of backward compatibility with 5.6, I use lexical filehandles instead of barewords:

    open my $data, ...
    Moreover, I usually stick to the three argument version of open(), not because this is requested by this particular application (I actually don't know), but more for sake of a mental habit (yes, I'm mental :) :
    open my $data, '<', $files{$_} ...
    I find it better not only because it avoids nasty problems when the filename comes from the "untrusted external" (which could lead to embarassing security holes), but also because it visually marks that this open is for read instead of write.

    Last, even if the plain die does the work (especially in pseudocode!), it could be helpful to provide a more sensible feedback message, either directly:

    open my $data, '<', $files{$_} or die "open('$files{$_}'): $!";
    or with
    use Fatal qw( open );
    in the script's preamble.

    Forgive me for jumping on your shoulders this way, but the OP seems to have some bias towards blind cut-and-paste, you know, so it could be useful for her|him to think about these issues ;)

    Flavio
    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.

      Regarding the open(), at the price of backward compatibility with 5.6, I use lexical filehandles instead of barewords:

      Lexical handles (and 3-arg open) work fine in 5.6.

      >c:\progs\perl560\bin\perl script.pl open(my $data, '<', $0) or die; print while <$data>;

      Lexical handles were introduced in 5.6, so you are sacrificing backwards compatibility wih 5.5 (5.005).

      What was introduced in 5.8 is file handles to variables (open(my $fh, '<', \$buf)).

      Heh, no worries. I wasn't exactly trying to meet stellar code standards. It was the best I could spit out in about 30-40 seconds ;)
Re^2: Working with a unkown number of arrays
by wojtyk (Friar) on Feb 05, 2007 at 17:04 UTC
    That open(DATA) line should be:
    open(*DATA,$files{$_}) or die;
    You get the point though.

        Update - I promise to read all of the thread before commenting next time. this was all already covered

        wait, why are we opening DATA, isn't that listed in perldata as a magical filehandle, attached to all the cruft after __DATA__ or __END__ at the end of your script?

        not that it matters here, but it's woth noting ... also, perhaps a lexical filehandle

        @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;