Wiggins, Thanks for the reply. This is what I understood as well.
The is the reason why I didn't have: script.pl -a something -b "something else" -c another_one -d etc is because I really wanted to say: script.pl -a something -b something -e else -c another_one -d etc I found out that in another script I did a similar thing where I had my options that it ignored as optional (meaning -c and -d were optional). This caused the script to succeed, but gave different results - something that I would see after a long time has passed and results would cause other problems. Since my scripts are used by everyone in my organization, this could cause undesired results for them (if they did not understand the impact of getting the syntax right). So to make my script dummy proof, I am trying to find easy ways of parsing the input the getopts ignores. I guess what I am looking for is a getopt::std that saves the part that it ignores in a special variable. Does anyone do this ? I don't like the getopt::long because I use many options. Also with the -- & something=something, things look ugly and the developers like things simple. Thanks in advance, Jayesh -----Original Message----- From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 7:12 PM To: Jayesh Patel Cc: '[EMAIL PROTECTED]' Subject: Re: getopt::std problem ignoring options Jayesh Patel wrote: > Hi all, > > Just wondering how some of you are handling this issue that I have. > I am using the getopt::std. When I pass in parameters to my script with > a possible mistake, the getopts ignores the rest of my switches. > For example: > > script.pl -a something -b something else -c another_one -d etc > > when getopts gets to the else, it doesn't proceed and populate my hash > for c or d. Just populates a and b. Anyone have any idea ? > > I'm using Active Perl 5.6.1 & Getopt/Std.pm 1.02 > > I looked at other getopt modules on CPAN - too many to look thru. Any > recommendations ?? This is I believe known and expected behavior, and a fault with getopt from the c lib or the regular shells, or somewhere in the bowels of Unix history. Essentially before long options came along programs only recognized short options, and as soon as they came upon a non-option then they assumed everything thereafter was an argument, or a file list, etc. the module is just parsing everything that is in @ARGV up until it hits a value but not a recognized option, and then assumes you will handle the rest of ARGV on your own. To the best of my knowledge which is obviously not all encompassing there is no way to force Getopt::Std into the mindset to work around this little problem, however there is Getopt::Long which does in fact cure this ailment, from the Getopt::Long docs: "Mixing command line option with other arguments Usually programs take command line options as well as other arguments, for example, file names. It is good practice to always specify the options first, and the other arguments last. Getopt::Long will, how- ever, allow the options and arguments to be mixed and 'filter out' all the options before passing the rest of the arguments to the program. To stop Getopt::Long from processing further arguments, insert a double dash "--" on the command line: --size 24 -- --all In this example, "--all" will not be treated as an option, but passed to the program unharmed, in @ARGV." perldoc Getopt::Long For those of the GNU generation like myself this will better match the behavior you are used to.... http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
