How to access multiple option values from hash specification - perl

use Getopt::Long;
GetOptions(\%gOptions,
"help",
"size=i",
"filename=s{2}",
);
I am passing options like -
--size 200 --filename abc.txt def.txt
I tried accessing filename from the hash specification through
my #array = $gOptions{filename};
print $array[0];
print $array[1];
However, this is not working. How to access multiple option values from a hash specification %gOptions?
Note :
I can map filename to separate array like this -
"filename=s{2}" => \#filearray,
print "$filearray[1];"
but I am not preferring this method.

The documentation on this form of usage says:
For options that take list or hash values, it is necessary to indicate this by appending an # or % sign after the type
and it will then use a reference to an array or hash in the appropriate field to hold values.
So...
#!/usr/bin/env perl
use warnings;
use strict;
use feature qw/say/;
use Getopt::Long;
my %gOptions;
GetOptions(\%gOptions,
"help",
"size=i",
# The # has to come after the type, and before the repeat count.
# Note the single quotes so #{2} isn't subject to variable interpolation
'filename=s#{2}',
);
say for $gOptions{"filename"}->#* if exists $gOptions{"filename"};
# or #{$gOptions{"filename"}} if your perl is too old for postderef syntax
Example:
$ perl foo.pl --filename a b
a
b

Related

Is possible iteration over undefined dereferenced array a bug or a feature?

Following code crashes as expected, because $x does not hold Array reference:
$ perl -E 'use strict; use warnings; my $x; say #{$x}; say "OK";'
Can't use an undefined value as an ARRAY reference at -e line 1.
However this code works without any warning:
perl -E 'use strict; use warnings; my $x; say for #{$x}; say "OK";'
OK
Why? I have not found any documentation of this behavior in perldoc.
Looks like for context is implying some DWIM-ness logic here (with dangerous consequences).
This is hopefully somewhat enlightening:
$ perl -E 'use strict; use warnings; my $x; say for #{$x}; say $x;'
ARRAY(0x561b92479420)
The $x variable is being autovivified by for.
Compare with:
$ perl -E 'use strict; use warnings; my $x; $x->[0]; say $x;'
Useless use of array element in void context at -e line 1.
ARRAY(0x561b92479420)
Certain reference operations on undefined scalars will cause autovivification to happen. for #{$var} is apparently one of them. There is a autovivication module on CPAN that allows you more control over when autovivification happens.
You have this statement:
say for #{$x}
The value of $x is undef, so when you dereference it, Perl notices that you want to use $x as an array ref. It then creates the array for you ("autovivification"). That array is empty, so there's nothing that for can iterate over.
Autovivification is the feature that enables us to do tasks like counting in this loop. When a key for $first doesn't exist, Perl adds that key to the hash. But, there needs to be a second level hash where $second can be a key. Since the value of the $first key is undef, Perl autovivifies that second level hash so you can operate on it:
for ( ... ) {
# source.example.com dest.example.org 1234
my( $first, $second, $count ) = split;
$hash->{$first}{$second} += $count;
}
Image how hard this task would be if you had to know all the keys, hash sizes, and so on in advance, or had to extend or modify the data structure sizes yourself.
We have an extended example of this in Intermediate Perl, the book in the tutorial series where we talk about references. I also write about it in Understand autovivification.
#tobyink mentions the autovificiation pragma. It recognizes certain constructs and can warn or stop your program:
use v5.10;
use warnings;
no autovivification qw(store);
my $x;
for ( #$x ) {
say "Got value: $_";
}
say "End. x = $x";
Now the program stops:
Can't vivify reference at ...
But, all of this makes your program a bit slower as Perl has to do extra work to check all that.
There's also the StackOverflow answer How do I disable autovivification in Perl?, but I think the answers aren't that useful.
You should get used to autovivification and programming in an environment where it exists (along with all the other things that you can accidentally do to create bugs).

Issues with getopts in perl

I'm using Getopt::Std to process my command line args. My command line args are strings. I have issuewithgetopts()`, as it works only for single character based opts.
As seen below "srcdir" "targetdir" options are mandatory and script should error out if any one of them is missing. "block" is NOT a mandatory option.
I don't see %options has is being set with the code below, and all my options{key} are NULL. Had I replaced "srcdir=>s" and "targetdir=>t" then the below piece of code works. It doesn't work with "-srcdir" "-targetdir" options.
What's the best way to address the issue I have?
Use mode:
perl test.pl -srcdir foo1 -targetdir hello1
#!/usr/bin/perl -w
use strict;
use Getopt::Std;
# declare the perl command line flags/opt we want to allow
my %options=();
my $optstring = 'srcdir:targetdir:block';
getopts( "$optstring", %options);
# test for the existence of the opt on the command line.
print "-srcdir $options{srcdir}\n" if defined $options{srcdir};
print "-targetdir $options{targetdir}\n" if defined $options{targetdir};
print "-blocks $options{block}\n" if defined $options{block};
# other things found on the command line
print "loop:\n" if ($#ARGV > 0);
foreach (#ARGV)
{
print "$_\n";
}
You really want to use Getopt::Long to handle words like srcdir:
use warnings;
use strict;
use Data::Dumper;
use Getopt::Long;
$Data::Dumper::Sortkeys=1;
my %options;
GetOptions(\%options, qw(srcdir=s targetdir=s block));
print Dumper(\%options);
print Dumper(\#ARGV);
The reason your hash was empty was that you need to pass a reference to a hash, as shown in Getopt::Std:
getopts( "$optstring", \%options);
Also, since Std only handles single letters, it would interpret srcdir as 6 separate options: s, r, etc.

Read optional command-line arguments in Perl

I am new to Perl and I'm confused with its handling of optional arguments.
If I have a perl script that's invoked with something along the lines of:
plgrep [-f] < perl regular expression > < file/directory list >
How would I determine whether or not the -f operator is given or not on the command line?
All of the parameters passed to your program appear in the array #ARGV, so you can simply check whether any of the array elements contain the string -f
But if you are writing a program that uses many different options in combination, you may find it simpler to use the Getopt::Long module, which allows you to specify which parameters are optional, which take values, whether there are multiple synonynms for an option etc.
A call to GetOptions allows you to specify the parameters that your program expects, and will remove from #ARGV any that appear in the command line, saving indicators in simple Perl variables that reflect which were provided and what values, if any, they had
For instance, in the simple case that you describe, you could write your code like this
use strict;
use warnings 'all';
use feature 'say';
use Getopt::Long;
use Data::Dump;
say "\nBefore GetOptions";
dd \#ARGV;
GetOptions( f => \my $f_option);
say "\nAfter GetOptions";
dd $f_option;
dd \#ARGV;
output
Before GetOptions
["-f", "regexp", "file"]
After GetOptions
1
["regexp", "file"]
So you can see that before the call to GetOptions, #ARGV contains all of the data in the command line. But afterwards, the -f has been removed and variable $f_option is set to 1 to indicate that the option was specified
Use Getopt::Long. You could, of course, parse #ARGV by hand (which contains command line arguments), but there is no reason to do that with the existence of good modules for the job.
use warnings;
use strict;
use Getopt::Long;
# Set up defaults here if you wish
my ($flag, $integer, $float, $string);
usage(), exit if not GetOptions(
'f|flag!' => \$flag,
'integer:i' => \$integer,
'float:f' => \$float,
'string:s' => \$string
);
# The script now goes. Has the flag been supplied?
if (defined($flag)) { print "Got flag: $flag\n" } # it's 1
else {
# $flag variable is 'undef'
}
sub usage {
print "Usage: $0 [options]\n"; # -f or -flag, etc
}
The $flag can simply be tested for truth as well, if that is sufficient. To only check whether -f is there or not, need just: GetOptions('f' => \$flag); if ($flag) { };.
The module checks whether the invocation specifies arguments as they are expected. These need not be entered, they are "options." However, for an unexpected invocation a die or warn message is printed (and in the above code our usage message is also printed and the script exits). So for script.pl -a the script exits with messages (from module and sub).
Abbreviations of option names are OK, if unambiguous; script.pl -fl 0.5 exits with messages (-flag or -float?) while script.pl -i 5 is OK and $integer is set to 5. On the other hand, if an integer is not supplied after -i that is an error, since that option is defined to take one. Multiple names for options can be specified, like f|flag. Etc. There is far more.

Using Data::Printer with qx operator

I was experimenting with the Data::Printer module, and it worked fine until
I tried to print the return value of a system call using qx operator:
use strict;
use warnings;
use Data::Printer;
p qx/echo -n Hello/;
This gives me the following error:
Type of arg 1 to Data::Printer::p must be one of [#$%&] (not scalar)
I assume this error occurs because qx is not recognized as a scalar, hash, array, or function. So I tried:
p my $temp = qx/echo -n Hello/;
and it worked fine. The question is, if it is possible to avoid the use of the $temp variable? (I think this syntax would become annoying to use and remember in the long run)
Unlike Data::Dumper and Data::Dump, the default mode of Data::Printer allows you to display only the contents of variables, not arbitrary expressions
This behaviour can be circumvented by disabling the use_prototypes option in the use statement, when arrays and hashes must be passed explicitly by reference
use Data::Printer use_prototypes => 0, output => 'stdout';
p qx/echo -n Hello/;
output
"Hello"

How can I allow undefined options when parsing args with Getopt

If I have a command line like:
my_script.pl -foo -WHATEVER
My script knows about --foo, and I want Getopt to set variable $opt_foo, but I don't know anything about -WHATEVER. How can I tell Getopt to parse out the options that I've told it about, and then get the rest of the arguments in a string variable or a list?
An example:
use strict;
use warnings;
use Getopt::Long;
my $foo;
GetOptions('foo' => \$foo);
print 'remaining options: ', #ARGV;
Then, issuing
perl getopttest.pl -foo -WHATEVER
gives
Unknown option: whatever
remaining options:
You need to configure "pass_through" option via Getopt::Long::Configure("pass_through");
Then it support actual options (e.g. stuff starting with "-" and without the special "--" delimiter to signify the end of "real" options).
Here's perldoc quote:
pass_through (default: disabled)
Options that are unknown, ambiguous or supplied with an invalid option value are passed through in #ARGV instead of being flagged as errors. This makes it possible to write wrapper scripts that process only part of the user supplied command line arguments, and pass the remaining options to some other program.
Here's an example
$ cat my_script.pl
#!/usr/local/bin/perl5.8 -w
use Getopt::Long;
Getopt::Long::Configure("pass_through");
use Data::Dumper;
my %args;
GetOptions(\%args, "foo") or die "GetOption returned 0\n";
print Data::Dumper->Dump([\#ARGV],["ARGV"]);
$ ./my_script.pl -foo -WHATEVER
$ARGV = [
'-WHATEVER'
];
Aren't the remaining (unparsed) values simply left behind in #ARGV? If your extra content starts with dashes, you will need to indicate the end of the options list with a --:
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
use Data::Dumper;
my $foo;
my $result = GetOptions ("foo" => \$foo);
print Dumper([ $foo, \#ARGV ]);
Then calling:
my_script.pl --foo -- --WHATEVER
gives:
$VAR1 = [
1,
[
'--WHATEVER'
]
];
PS. In MooseX::Getopt, the "remaining" options from the command line are put into the extra_argv attribute as an arrayref -- so I'd recommend converting!
I think the answer here, sadly though, is "no, there isn't a way to do it exactly like you ask, using Getopt::Long, without parsing #ARGV on your own." Ether has a decent workaround, though. It's a feature as far as most people are concerned that any option-like argument is captured as an error. Normally, you can do
GetOptions('foo' => \$foo)
or die "Whups, got options we don't recognize!";
to capture/prevent odd options from being passed, and then you can correct the user on usage. Alternatively, you can simply pass through and ignore them.