Sponsored Content
Top Forums Programming Reading long options in C++ program Post 302611895 by kristinu on Friday 23rd of March 2012 05:42:33 PM
Old 03-23-2012
This is what I have.

Code:
      if (strncmp(argv[i], "--", 2) == 0) {      // First two characters match '--'.

          // If '=' is detected, point to its first occurrence.
          const char* after = strchr(argv[i], '=');

//          String Name;               // Make it a 'String' so we can use ToUpper.

          // Detected '--key value'. Set key, and get value from next argument.
          if (after == NULL) {
            SKey = String(argv[i]);    // Convert key to 'String' so we can use ToUpper.
            ++i;                       // Move to next argument (one argument forward).
            if (i == argc) {           // Quit if next argument not found, rather than crashing.
              error("Out of arguments");
              continue;
            }
            value = argv[i];           // Set value from next argument.
            SValue = String(value);

          // Detected '--key=value'. Get value from next argument.
          } else {
            String S = String(argv[i]);
            Search(S, "=", poseq);
            SKey = ToUpper( S.Substr(2, poseq-1) );
            value = after + 1;          // Set user input. "=file"+1 is "file".
            SValue = String(value);
          }

          cout << "Key = " << SKey << ", Value = " << SValue << endl << endl;
          Index += ParseEl(SKey, SValue, Ord);

      } else {

          String Msg = "Long options must be introduced by a double dash '--'. '";
          error(Msg + String(argv[i]) + "'");

      }

So I am wondering what improvements I can have to remove clutter.
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

reading long filenames from nero to AIX

One of my colleagues is having an issue moving files between a windows box and the AIX servers in the office. The filenames are being truncated though i don't know to what extent. He's using Nero to burn the CD and I think he mentioned he's using Joliet. I found another thread that shows a... (1 Reply)
Discussion started by: categoryzd
1 Replies

2. Shell Programming and Scripting

Help with shell script to run the commands reading options from local file

I have to use shell script to run series of commands on another unix box by connecting through SSH and giving user credentials. For running commands on remote machine I have to use options reading from a local file. Process: Connecting to remote unix server <host1.ibm.com> through ssh Login: ... (2 Replies)
Discussion started by: itsprout
2 Replies

3. Shell Programming and Scripting

using getopt for both short and long options

Hi , I am using getopt for both short and long options as below SHORTOPTS="a:c" LONGOPTS="alpha:,charlie" OPTS=$(getopt -o $SHORTOPTS --longoptions $LONGOPTS -n "$progname" -- "$@") eval set -- "$OPTS" while ; do case $1 in -a|--alpha) echo "-a or --alpha... (0 Replies)
Discussion started by: padmisri
0 Replies

4. Shell Programming and Scripting

using getopt for both short and long options

Hi , I am using getopt for both short and long options as below SHORTOPTS="a:c" LONGOPTS="alpha:,charlie" OPTS=$(getopt -o $SHORTOPTS --longoptions $LONGOPTS -n "$progname" -- "$@") eval set -- "$OPTS" while ; do case $1 in -a|--alpha) echo "-a or --alpha... (1 Reply)
Discussion started by: padmisri
1 Replies

5. Shell Programming and Scripting

using getopt for both short and long options

Hi , I am using getopt for both short and long options as below SHORTOPTS="a:c" LONGOPTS="alpha:,charlie" OPTS=$(getopt -o $SHORTOPTS --longoptions $LONGOPTS -n "$progname" -- "$@") eval set -- "$OPTS" while ; do case $1 in -a|--alpha) echo "-a or --alpha... (1 Reply)
Discussion started by: padmisri
1 Replies

6. Shell Programming and Scripting

Reading command options one by one

Hi, Just some questions on the script below...? Given: bash-2.03$ command -a option1 name1 name2 ParseOptions() { local Len=${#@} local Ctr=2 #always start at 2 local Name=() local Iter=0 while ; do if <- Is this correct? so I can get the $2... (2 Replies)
Discussion started by: h0ujun
2 Replies

7. Shell Programming and Scripting

Reading command line options from bash script

I have the following code and I am calling it using ./raytrac.bash -u and getting problems. For some reason opt_usage is still 0. opt_usage=0 iarg=0 narg=$# while (($iarg < $narg)) do (( iarg = $iarg + 1 )) arg=$argv usrInputFlag=`echo $arg | awk '/=/ {print 1}; ! /=/... (22 Replies)
Discussion started by: kristinu
22 Replies

8. Shell Programming and Scripting

How to display a message if program hangs(takes too long)

I have a ksh script (script1) that calls another ksh script (script2). If script2.ksh hangs or takes too long to execute I want script1.ksh to kill the call to script2.ksh and instead just display "Script2 can't run right now". Could someone help me with coding this? (1 Reply)
Discussion started by: mrskittles99
1 Replies

9. Shell Programming and Scripting

Perl :: Getopt::Long in the program

While going through some of the perl script... I had found the below line.. use Getopt::Long; my $GetOptionsReturnCode = GetOptions ( '<>' => sub { push(@unknownArg, @_); }, 'h|help' => sub { &helpMessage(); exit 0; }, ); Could anyone please explain the above one ... (1 Reply)
Discussion started by: scriptscript
1 Replies

10. Shell Programming and Scripting

Reading a long literal continued next line

I am trying to identify all messages or prompts from a number of COBOL programs and they can usually be identified by a pair of double quotes on one line. However, sometimes the literal will not be finished on the first line but after a dash in column 7 of the next line, the literal will be... (6 Replies)
Discussion started by: wbport
6 Replies
Getopt::Long::Descriptive(3pm)				User Contributed Perl Documentation			    Getopt::Long::Descriptive(3pm)

NAME
Getopt::Long::Descriptive - Getopt::Long, but simpler and more powerful VERSION
version 0.091 SYNOPSIS
use Getopt::Long::Descriptive; my ($opt, $usage) = describe_options( 'my-program %o <some-arg>', [ 'server|s=s', "the server to connect to" ], [ 'port|p=i', "the port to connect to", { default => 79 } ], [], [ 'verbose|v', "print extra stuff" ], [ 'help', "print usage message and exit" ], ); print($usage->text), exit if $opt->help; Client->connect( $opt->server, $opt->port ); print "Connected! " if $opt->verbose; ...and running "my-program --help" will produce: my-program [-psv] [long options...] <some-arg> -s --server the server to connect to -p --port the port to connect to -v --verbose print extra stuff --help print usage message and exit DESCRIPTION
Getopt::Long::Descriptive is yet another Getopt library. It's built atop Getopt::Long, and gets a lot of its features, but tries to avoid making you think about its huge array of options. It also provides usage (help) messages, data validation, and a few other useful features. FUNCTIONS
Getopt::Long::Descriptive only exports one routine by default: "describe_options". All GLD's exports are exported by Sub::Exporter. describe_options my ($opt, $usage) = describe_options($usage_desc, @opt_spec, \%arg); This routine inspects @ARGV returns the options given and a object for generating usage messages. The $opt object will be a dynamically-generated subclass of Getopt::Long::Descriptive::Opts. In brief, each of the options in @opt_spec becomes an accessor method on the object, using the first-given name, with dashes converted to underscores. For more information, see the documentation for the Opts class. The $usage object will be a Getopt::Long::Descriptive::Usage object, which provides a "text" method to get the text of the usage message and "die" to die with it. For more methods and options, consults the documentation for the Usage class. $usage_desc The $usage_desc parameter to "describe_options" is a "sprintf"-like string that is used in generating the first line of the usage message. It's a one-line summary of how the command is to be invoked. A typical usage description might be: $usage_desc = "%c %o <source> <desc>"; %c will be replaced with what Getopt::Long::Descriptive thinks is the program name (it's computed from $0, see "prog_name"). %o will be replaced with a list of the short options, as well as the text "[long options...]" if any have been defined. The rest of the usage description can be used to summarize what arguments are expected to follow the program's options, and is entirely free-form. Literal "%" characters will need to be written as "%%", just like with "sprintf". @opt_spec The @opt_spec part of the args to "describe_options" is used to configure option parsing and to produce the usage message. Each entry in the list is an arrayref describing one option, like this: @opt_spec = ( [ "verbose|V" => "be noisy" ], [ "logfile=s" => "file to log to" ], ); The first value in the arrayref is a Getopt::Long-style option specification. In brief, they work like this: each one is a pipe-delimited list of names, optionally followed by a type declaration. Type declarations are '=x' or ':x', where "=" means a value is required and ":" means it is optional. x may be 's' to indicate a string is required, 'i' for an integer, or 'f' for a number with a fractional part. The type spec may end in "@" to indicate that the option may appear multiple times. For more information on how these work, see the Getopt::Long documentation. The first name given should be the canonical name, as it will be used as the accessor method on the $opt object. Dashes in the name will be converted to underscores, and all letters will be lowercased. For this reason, all options should generally have a long-form name. The second value in the arrayref is a description of the option, for use in the usage message. Special Option Specifications If the option specification (arrayref) is empty, it will have no effect other than causing a blank line to appear in the usage message. If the option specification contains only one element, it will be printed in the usage message with no other effect. If the option specification contains a third element, it adds extra constraints or modifiers to the interpretation and validation of the value. These are the keys that may be present in that hashref, and how they behave: implies implies => 'bar' implies => [qw(foo bar)] implies => { foo => 1, bar => 2 } If option A has an "implies" entry, then if A is given, other options will be enabled. The value may be a single option to set, an arrayref of options to set, or a hashref of options to set to specific values. required required => 1 If an option is required, failure to provide the option will result in "describe_options" printing the usage message and exiting. hidden hidden => 1 This option will not show up in the usage text. You can achieve the same behavior by using the string "hidden" for the option's description. one_of one_of => @subopt_specs This is useful for a group of options that are related. Each option spec is added to the list for normal parsing and validation. Your option name will end up with a value of the name of the option that was chosen. For example, given the following spec: [ "mode" => hidden => { one_of => [ [ "get|g" => "get the value" ], [ "set|s" => "set the value" ], [ "delete" => "delete it" ], ] } ], No usage text for 'mode' will be displayed, but text for get, set, and delete will be displayed. If more than one of get, set, or delete is given, an error will be thrown. So, given the @opt_spec above, and an @ARGV of "('--get')", the following would be true: $opt->get == 1; $opt->mode eq 'get'; Note: "get" would not be set if "mode" defaulted to 'get' and no arguments were passed in. Even though the option sub-specs for "one_of" are meant to be 'first class' specs, some options don't make sense with them, e.g. "required". As a further shorthand, you may specify "one_of" options using this form: [ mode => @option_specs, \%constraints ] Params::Validate In addition, any constraint understood by Params::Validate may be used. (Internally, all constraints are translated into Params::Validate options or callbacks.) %arg The %arg to "describe_options" is optional. If the last parameter is a hashref, it contains extra arguments to modify the way "describe_options" works. Valid arguments are: getopt_conf - an arrayref of strings, passed to Getopt::Long::Configure prog_name This routine, exported on demand, returns the basename of $0, grabbed at compile-time. You can override this guess by calling "prog_name($string)" yourself. OTHER EXPORTS
"-types" Any of the Params::Validate type constants ("SCALAR", etc.) can be imported as well. You can get all of them at once by importing "-types". "-all" This import group will import "-type", "describe_options", and "prog_name". CUSTOMIZING
Getopt::Long::Descriptive uses Sub::Exporter to build and export the "describe_options" routine. By writing a new class that extends Getopt::Long::Descriptive, the behavior of the constructed "describe_options" routine can be changed. The following methods can be overridden: usage_class my $class = Getopt::Long::Descriptive->usage_class; This returns the class to be used for constructing a Usage object, and defaults to Getopt::Long::Descriptive::Usage. SEE ALSO
o Getopt::Long o Params::Validate AUTHORS
o Hans Dieter Pearcey <hdp@cpan.org> o Ricardo Signes <rjbs@cpan.org> COPYRIGHT AND LICENSE
This software is copyright (c) 2005 by Hans Dieter Pearcey. This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. perl v5.14.2 2012-02-22 Getopt::Long::Descriptive(3pm)
All times are GMT -4. The time now is 10:57 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy