Re: Empowered by Perl

[LighthouseJ]

I find myself writing a lot of scripts these last few weeks for work. I use sh scripting for little things like "ps | awk" but I find myself going to perl when there's any substantial level of complexity.

I have found perl a little lacking in two operations though which has turned me back to shell a few times.

1. I want to just open a file and dump it's contents like my @contents = contents "/my/text/file"; without an 'open' in a regular script (aka not in a one-liner). my @text = grep /important/, contents "/my/text/file" would be very convenient for me. It gets to be a hassle to juggle open's in some circumstances I run across.
2. I also want to change Perl's IRS which has been a hinderance for a while. I have made my own scripts which fix up the algorithm but I'm surprised Perl hasn't made it easier and more straight-forward.

[halley]

Doesn't seem pretty, but you don't have to deal with closing or colliding with the filehandle...

my @contents = do { open(my $fh, "/my/text/file") or die; <$fh> };

tye recommended something like this, some time ago.

my @contents = do { local *ARGV; @ARGV=('/my/text/file'); <> };

His also supports concatenation of multiple files, just add them in the parentheses.

[TGI]

You can easily put together a module to provide the contents function you describe. Or you could install File::Slurp, which provides several useful variants.

[LighthouseJ]

I often find myself only having the barebones stock Solaris installation. Installing a Perl Module is out of the question. Putting a function together might be too involved. The algorithms I've put together seem to work okay though so I guess it'll just be wishful thinking for the time being.

[mr_mischief]

There are the ways halley mentions (Re^2: Empowered by Perl) that are not at all involved. There are many other ways as well. I'm offering some of those others, but it's still not an exhaustive list of ways to do this.

If you're not tied to your syntax, try option 0. If you are, try option 1 or option 2. Note the localization of @ARGV, which is important if you need to specify the content file in the program and still need your command-line arguments. Option 1 always returns a list, so you get a count of lines in scalar context. Option 2 returns whatever the diamond operator read depending on the sub's context. It can be used to read all lines in list context or one line at a time, iteratively, in scalar context.

If you don't need to specify the file you need the contents from in the program and don't care about mangling @ARGV for other uses you can use option 3, which is what automatic @ARGV handling by <> is for. Note that will do the same for as many files as specified in @ARGV and will implicitly shift them off the array.

Option 4 is reminiscent of both Option 0 and options 1/2. It lets you specify a single filename on the command line so you don't have your global @ARGV messed with, but it doesn't use a sub.

Update: Following the same thinking as 0 through 4, option 5 is left for an exercise: Take a command-line argument and pass it to the subroutine from Option 1 or Option 2.

Option 0:

Read more... (439 Bytes)

Option 1:

Read more... (513 Bytes)

Option 2:

Read more... (498 Bytes)

Option 3:

Read more... (378 Bytes)

Option 4:

Read more... (504 Bytes)

Another approach is to just return what you actually want if you're not looking for all the contents anyway:

#!usr/bin/perl
use warnings;
use strict;

sub grepfile {
    local @ARGV = ( $_[1] );
    return grep /$_[0]/, <>;
}

my @text = grepfile 'important', './grepfile';
print @text, "\n";
print @ARGV, "\n";

Of course, this is not the prettiest Perl code out there. People might complain that you're messing with your tools in ways other than intended. Others would counter, though, that that's what happens with powerful, successful software.