Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chaoticset (2105)

  (email not shown publicly)
AOL IM: chaoticset23 (Add Buddy, Send Message)
Yahoo! ID: illuminatus_foil (Add User, Send Message)

JAPH. (That's right -- I'm not Really Inexperienced any more.)

I'm not just here, I'm here [], and here [] too, I ramble randomly in my philosophical blog [] and my other blog []. Soon I'll come in a convenient six-pack.

Journal of chaoticset (2105)

Friday November 08, 2002
12:53 AM


[ #8831 ]
I've lost the battle, and perhaps the war too. I simply cannot keep up with the site any more, and while that's been ongoing, I freely admit it now. I don't have the time, and even if I did, I'm not scanning everybody, there's simply too much journal activity.

That having been said, I noted something recently. A while back I wrote some specific functions that essentially were wrappers for open() with various modes. My sanity check kicked in after I wrote a couple, and I realized that I didn't really need to do it -- open was really as clean as it got without sacrificing functionality. Having an append() and readfile() and closefile() etc. just cluttered up namespace.

This was some time back. Recently, I've had to parse an entire directory, for which I discovered opendir. It has occurred to me that opendir does not have the niceties that open has -- filehandles don't work with while without a little extra arcana, stripping out the . and .. files and skipping unreadables without dying and a few other things. These little typing exercises from the Ram weren't upsetting until I started the second thing that included them, and the magic word "refactoring" floated to the top of my mind.

"Gee. Couldn't I build a little wrapper to these, something that returns a list of files in the directory minus the . and .. at the very least? Wouldn't that help with readability, since you're adding all this quickly-typed but line-noise-reminiscent code to handle some special situations and whatnot? I mean, since you're adding stuff to warn on unreadables and all that, you might as well go whole hog, make functions that return 1 for a completely well-read directory and return a list of files that didn't work for an error..."

The voice is still going. I think it's a good idea, and I'm going to attempt a refactor tomorrow to help me write the guts of my GUI (since the GUI is going to require essentially the same directory-opening activity as the command-line filter system.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • sub allfiles
        use Carp;
        my($dirname) = @_;
        opendir my $dh, $dirname or croak "Can't open $dirname: $!";
        my @files = grep {not m/^\./} readdir $dh;
        closedir $dh || carp "Couldn't close $dirname: $!";
        return @files;

    And then I'm known to do things like

    map { ... } grep { ... } sort allfiles($dir)

    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Couldn't I build a little wrapper to these, something that returns a list of files in the directory minus the . and .. at the very least?

    You can use

    @files = glob('*');

    which returns a list of all files for the current directory, and doesn't include "." and "..".

    You can use a full, absolute or relative path in front of the "*", to get a listing for other directories; but be aware that, by contrast to opendir()/readdir(), the results do include the said path. For opening the files that's a good thing, bu