Re: Parsing Command Line Options

I think you want to just quote your values in your shell:

use warnings;
use strict;
use Getopt::Long;

my $location;
my $user_cfg;

#Define argument types
GetOptions('location=s' => \$location,
       'cfg=s' => \$user_cfg);

#Check if cfg option was specified
if ($user_cfg) {
     #Replace any spaces found in a "quoted" filename
     #i.e. ("sample test" --> "sample-test")
         $user_cfg =~ s/\s+/-/g;
}

print "location = $location\n";
print "cfg File = $user_cfg\n";

__END__


$ ./my_script --cfg='my test 2.cfg' --location='fake location name'

location = fake location name
cfg File = my-test-2.cfg
[download]

is there some kind of global variable (like $?, $!, etc...) that holds that entire line just executed through the command line

$0 stores the command name and @ARGV stores all the arguments. Getopt::Long parses @ARGV.

Comment on Re: Parsing Command Line Options Download Code

Replies are listed 'Best First'.
Re^2: Parsing Command Line Options by mmartin (Monk) on Jan 12, 2012 at 20:57 UTC
toolic, Sorry I didn't see the 2nd half of your reply about the $0 and ARGV stuff... Sweet, I'll give that a try. But it sounds like that's what I'm looking for. Thanks Again, Matt	[reply]
Re^2: Parsing Command Line Options by mmartin (Monk) on Jan 12, 2012 at 20:51 UTC
Hey toolic, thanks for the reply. Right, if they quote it it would not be a problem. But some people using this may not be the most computer savvy people, and I want to just make sure they can't screw it up. Thanks, Matt	[reply]
Re^3: Parsing Command Line Options by Tanktalus (Canon) on Jan 12, 2012 at 21:05 UTC
If they're not that savvy, tell them to stop using spaces in their filenames ;-) There really is no straight-forward, simple, and portable answer to your question, short of some minor retraining of your users. For example, if I specify "`--cfg=my cfg`" with two spaces, there's basically no way to recover that - the shell will eat the spaces. (Some shells may save the original command in an environment variable, but, again, it's not portable, and may not apply to your shell/OS/users.) You could, I suppose, use *'s instead of -'s or _'s and the glob function, but at some point you're getting far too smart and will likely end up getting in trouble. If you continue to try, you may have to pre-process @ARGV, merging any argument that doesn't start with a dash in with the previous argument. But, even then, it gets annoying, really fast. Also, your interface will be completely non-standard. Users learning your way of doing things will not be able to apply that knowledge to any other application. However, if you teach them the "normal" way (quoting, or just putting in the dashes if that's what they want to use), that knowledge and experience will then transfer to any other program they use. Sounds like what you really need is a GUI interface for users who can't handle the command line :-) (And lest that sound condescending, it's not intended to - presumably those users are providing other value to their employer to justify their salary which would be more valuable than another command-line expert :-) )	[reply] [d/l]
Re^4: Parsing Command Line Options by mmartin (Monk) on Jan 12, 2012 at 21:16 UTC
Hey Tanktalus, thanks for your reply. Yeah, I guess your right... I was afraid of that lol. Ok, I guess I'll just make sure that they use some kind of separators (i.e. '-' or '_')... Thanks for the HARD truth haha... Thanks Again, Matt	[reply]