GetOptions option with value and no space

kopolov has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks, I'm trying to use GetOptions to a very simple program:

#!/usr/bin/perl -w
use Getopt::Long;

$myOpt=0;

GetOptions('S=i'=> \$myOpt);
print"$myOpt\n";
[download]

The file name is tst.pl

When I run this command:

./tst.pl -s 4

I get this result

However, when I run the same command without space between option and its value:

./tst.pl -s4

I get this error:

Unknown option: s4

I looked into Getopt::Long and saw that this form of option should be supported.

Any idea?

Comment on GetOptions option with value and no space Download Code

Replies are listed 'Best First'.
Re: GetOptions option with value and no space by 1nickt (Canon) on Jul 12, 2015 at 12:59 UTC
For what you want you need a couple of Getopt::Long options. `[05:53][nick:~/monks]$ cat 1134359.pl #! perl -w use strict; use Getopt::Long; Getopt::Long::Configure( "bundling", "ignorecase_always" ); my $myOpt=0; GetOptions('S=i'=> \$myOpt); print"S: $myOpt\n"; __END__ [05:53][nick:~/monks]$ perl 1134359.pl -S 6 S: 6 [05:53][nick:~/monks]$ perl 1134359.pl -s 6 S: 6 [05:53][nick:~/monks]$ perl 1134359.pl -S6 S: 6 [05:53][nick:~/monks]$ perl 1134359.pl -s6 S: 6` [download] The docs have much more to say on bundling options. Like what if you have an option `-foo` as well as `-f` and `-o`, the latter of which takes a required value when the others don't. What happens if the user does `script.pl -foo`? Maybe take note of the following line from the docs: "It goes without saying that bundling can be quite confusing." :-) `[05:53][nick:~/monks]$ perl 1134359.pl -zois6nks Unknown option: z Unknown option: o Unknown option: i Unknown option: n Unknown option: k Option s requires an argument S: 6` [download] Yep, still '6' ... Remember: Ne dederis in spiritu molere illegitimi!	[reply] [d/l] [select]
Re^2: GetOptions option with value and no space by kopolov (Acolyte) on Jul 13, 2015 at 07:24 UTC
Thank you !!! I've never noticed the bundling. This solved it	[reply]
Re: GetOptions option with value and no space by RichardK (Parson) on Jul 12, 2015 at 12:07 UTC
I don't think that is a bug, That's just how bundling works. see the bundling section in the docs Getopt::Long If you add `Getopt::Long::Configure ("bundling_values");` [download] It does what you want.	[reply] [d/l]
Re^2: GetOptions option with value and no space by u65 (Chaplain) on Jul 12, 2015 at 12:21 UTC
I see that bundling is disabled as the default, thus the OP problem script should work as I see it. update: Hm, when I use your configure 'bundling_values' the options should be case sensitive, but the original code has 'S=i' and when I execute: `$ ./tst.pl -S4` [download] I get `Unknown option: S4 0` [download]	[reply] [d/l] [select]
Re^3: GetOptions option with value and no space by tangent (Parson) on Jul 12, 2015 at 13:18 UTC
There does seem to be a problem with how the module handles case when "bundling_values" is turned on... When GetOptions is given 's=i' (lowercase) all works as expected: `Getopt::Long::Configure ("bundling_values"); my $myOpt = 0; GetOptions('s=i'=> \$myOpt); print "bundling_values\n"; print "$myOpt\n\n"; $ test.pl -S1 Unknown option: S1 bundling_values 0 $ test.pl -s1 bundling_values 1` [download] When GetOptions is given 'S=i' (uppercase) works opposite to expected: `Getopt::Long::Configure ("bundling_values"); my $myOpt = 0; GetOptions('S=i'=> \$myOpt); print "bundling_values\n"; print"$myOpt\n\n"; $ test.pl -S1 Unknown option: S1 bundling_values 0 $ test.pl -s1 bundling_values 1` [download] Workaround by adding 'ignorecase_always' option: `Getopt::Long::Configure ("bundling_values", "ignorecase_always"); my $myOpt = 0; GetOptions('S=i'=> \$myOpt); print "bundling_values, ignorecase_always\n"; print "$myOpt\n\n"; $ test.pl -S1 bundling_values, ignorecase_always 1 $ test.pl -s1 bundling_values, ignorecase_always 1` [download]	[reply] [d/l] [select]
Re: GetOptions option with value and no space by u65 (Chaplain) on Jul 12, 2015 at 11:28 UTC
I tried your code (as provided, and with 'use strict' added) and got the same results. Looks like a bug to me. update: It looks like the module has just been updated in June but the issue tracker seems not to have been updated. I tried the latest version and the bug is still there.	[reply]