Re^2: Extract the middle part of a list

[chrism01]

Guys,

Thx for both of those. I decided to go with Zaxo because it's simpler and works down the page (I think).
However, it's complaining about the curr/parent dir files (., ..) which i tried to fix, but I'm not good with these nested code layouts.
I tried:

@t_arr =
        grep {
          grep { $_ !~ /^\./ }
            $var3 = (split /[_.]/)[2];
            $var3 > $var1 and $var3 <= $var2;
            }
         readdir(EVT_DIR);

and a couple of variations, but still get warnings:

Use of uninitialized value in pattern match (m//) at ./t.pl line 341.
Use of uninitialized value in numeric gt (>) at ./t.pl line 345.
Use of uninitialized value in pattern match (m//) at ./t.pl line 341.
Use of uninitialized value in numeric gt (>) at ./t.pl line 345.

I also need to ignore any dirs that exist.
Any chance of the correct code?
Guess I need a tutorial article on nested code blocks (if that's the correct description)

Cheers
Chris

[Zaxo]

As you say, your blocking is incorrect. Here's how to write that:

@t_arr = grep {
    $var3 = (split /[_.]/)[2];
    $var3 > $var1 and $var3 <= $var2;
} grep {
    !-d and $_ !~ /^\./ 
} readdir(EVT_DIR);

where I've added !-d to exclude directories. You might want to use -f instead to admit only regular files.

[chrism01]

Zaxo,
close... it ignores curr, parent dirs fine, but still trips up over 'normal' dir. Tried it both as you said { !-d and $_ !~ /^\./ } and replace whole line with { -f }, no go.

Chris
BTW, am I right in believing that the logic is up/back for outer sub-blocks ie greps, but fwd/down for sub-block contents?
Also, why 'and' not '&&'?
This is a very educational thr (for me at least) :-)

[doom]

BTW, am I right in believing that the logic is up/back for outer sub-blocks ie greps, but fwd/down for sub-block contents?

Yes, essentially. Really perl reads everything from left-to-right, but it does "assignment" from right to left. With the usual formatting, it feels like the logical lines (seperated by semicolons) are being processed from top-to-bottom, but when you've got long chains of map/grep operations, it's traditional to put in line breaks, which makes it look like it's reading bottom-to-top, though really it's doing multiple assignments at once, going from right-to-left. Does that make sense?

A "Schwartzian" operation (sorting on a computed field), might seem like it's working bottom-to-top:

  @result = 
    map  { ... 3 ... }
    sort { ... 2 ... }
    map  { ... 1 ... };

But really it's doing assignment from right-to-left:

  @result = map  { ... 3 ... } sort { ... 2 ... } map  { ... 1 ... };

It does seem jarring to encounter a multi-line block in something like a grep, because it feels like the order of processing is jumping around: the whole program goes top-to-bottom, assignment in each logical line goes right-to-left, but then if you slip in a block with multiple lines, the top-to-bottom flow takes over again.