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
"Gee. Couldn't I build a little wrapper to these, something that returns a list of files in the directory minus the . and
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.)
I do this sometimes (Score:2)
And then I'm known to do things like
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Who needs a wrapper? (Score:1)
You can use
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