Ask a Question related to UNIX Programming, Design and Development.

  1. #1

    Default getopt in linux


    hi all,
    i am trying to use the getopt call of glibc in linux for parsing my
    command. What i am noticing that this function doesn't return to some of
    the options.I tried to understand more ab''t this in man page, but I
    still have some doubts :
    - does get opt look at all the arguments or does it neglect some of
    these
    e.g.1) char **op1=command -a arg1 -b arg2 -c arg3
    2)char **op2= -a arg1 -b arg2 -c arg3 -d arg4

    when used 'op2' getopt neglected the very first arg1 with -a option and
    when i used 'op1' it recognized all.

    can anyone please clearify this and is there any source to find more
    detail of this call as man page is quite confusing.

    thanks,
    np

    --
    Posted via [url]http://dbforums.com[/url]
    np_rpr Guest

  2. Similar Questions and Discussions

    1. Getopt::Std question
      When using Getopt::Std, if I use: getopts('c:'); ....and the user specifies the -c flag but fails to specify a parameter for the flag, such...
    2. Getopt::Simple V 1.47
      The pure Perl module Getopt::Simple V 1.47 is available immediately from CPAN, and from http://savage.net.au/Perl-modules.html. On-line docs,...
    3. Using Getopt::Std
      Hi, i am using the Getopt::Std package in my code. use Getopt::Std; getopts('s:'); $a = $opt_s
    4. using Getopt with subroutines
      Hello, I have a subroutine that is contained within its own module and package. It currently takes 7 different arguments, but only 2 of them are...
    5. Getopt module
      Deb wrote: Hello, No, you don't have strictures enabled (but you should have.) You are getting a warning because you have warnings enabled....
  3. #2

    Default Re: getopt in linux

    np_rpr <member33486@dbforums.com> wrote:
    >hi all,
    >i am trying to use the getopt call of glibc in linux for parsing my
    >command. What i am noticing that this function doesn't return to some of
    >the options.I tried to understand more ab''t this in man page, but I
    >still have some doubts :
    >- does get opt look at all the arguments or does it neglect some of
    > these
    > e.g.1) char **op1=command -a arg1 -b arg2 -c arg3
    > 2)char **op2= -a arg1 -b arg2 -c arg3 -d arg4
    >
    >when used 'op2' getopt neglected the very first arg1 with -a option and
    >when i used 'op1' it recognized all.
    The parameter list for getopt() looks like,

    int getopt(int argc, char * const argv[], const char *optstring);

    Note the second parameter is not a pointer to pointer to char,
    but rather an array of pointers to char (or, more easily
    understood, it is an array of pointers to strings). It should
    be declared as char opt1[], not char **op1.

    It is of course intended to be the argv array from

    main(int argc, char *argv[])

    Here is what the C Standard says that array is supposed to be:

    "If the value of argc is greater than zero, the string
    pointed to by argv[0] represents the program name;
    argv[0][0] shall be the null character if the program name
    is not available from the host environment. If the value of
    argc is greater than one, the strings pointed to by argv[1]
    through argv[argc-1] represent the program parameters."

    Obviously you most certainly do expect the first element of the
    array to be skipped over by the getopt() function, because it is
    the program name, not a command line argument.
    >can anyone please clearify this and is there any source to find more
    >detail of this call as man page is quite confusing.
    I would expect it to be explained in any C tutorial aimed at a
    unix environment.

    --
    Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
    Ukpeagvik (Barrow, Alaska) [email]floyd@barrow.com[/email]
    Floyd Davidson Guest

  4. #3

    Default Re: getopt in linux

    Floyd Davidson wrote:
    > Matthew Hails <matthew@nospam.nospam> wrote:
    > >Floyd Davidson wrote:
    > >> The parameter list for getopt() looks like,
    > >>
    > >> int getopt(int argc, char * const argv[], const char *optstring);
    > >>
    > >> Note the second parameter is not a pointer to pointer to char,
    > >> but rather an array of pointers to char (or, more easily
    > >> understood, it is an array of pointers to strings). It should
    > >> be declared as char opt1[], not char **op1.
    > >
    > >To be pedantic ...
    >
    > I don't think you actually said anything different than what
    > I did, except that you are applying the same terms to different
    > objects than I did.
    Ok, there's some truth in that. Let me explain my "terms" more fully:

    The formal parameter type is:
    pointer to pointer to char
    The actual argument expected is:
    pointer to array of pointer to char
    The variable declared in the calling function is likely to be:
    array of pointer to char
    > >Technically the second parameter *is* a pointer to (a const) pointer to
    > >char.
    >
    > Not in the prototype/declaration above!
    I disagree! It may look like it is, because it uses [], but really it's a
    pointer type, not an array. Try passing an array of pointers to char into
    a function with that prototype and I think you'll find that it always
    passes in a pointer to the array, not the array itself. Try passing in a
    pointer to pointer to char, and I think you'll find that it is passed in
    successfully.
    > > C allows you to declare the parameter using array syntax, but it
    > >actually is a pointer type. The reason (be it good or bad) for using the
    > >array syntax is to indicate that the caller should pass in a pointer to
    > >an array (of pointers to char), rather than just a pointer (to pointer
    > >to char).
    >
    > Well... isn't that exactly the point that I was making?
    Yes, I agree. It's just that you made it using a statement which I thought
    might be misleading.
    > >Of course, when you pass an array of pointer to char to the
    > >function, it will be converted to a pointer to its first element, that
    > >is, of type pointer to an array of pointer to char.
    > >(Sorry about all the pointers :-)
    > >
    > >It can be declared as any of the following (the array sizes and values
    > >are examples only):
    > >
    > > char * opt1[2];
    > > char ** opt2; /* Storage allocated/assigned later */
    > > char * const opt3[] = { "a", "b" };
    > > char * const * opt4 = opt3;
    >
    > True, but as noted, in this particular instance what it actually has
    > to be is is a pointer to an array. My reason for pointing that out
    > was because the pseudo code that was posted by the OP didn't make
    > it clear which it was.
    Yes. Sorry - I should have said in my previous post that your original
    reply was, in general, just what the OP needed.

    --
    Matthew Hails <matthew@hails.org.uk>

    Matthew Hails Guest

  5. #4

    Default Re: getopt in linux

    Floyd Davidson wrote:
    > Matthew Hails <matthew@nospam.nospam> wrote:
    >
    > >>Floyd Davidson wrote:
    > >
    > >>>> Matthew Hails <matthew@nospam.nospam> wrote:
    > >>
    > >>>>> >Floyd Davidson wrote:
    > >>>
    > >>>>>> >> The parameter list for getopt() looks like,
    > >>>>>> >>
    > >>>>>> >> int getopt(int argc, char * const argv[], const char *optstring);
    > >>>>>> >>
    > >>>>>> >> Note the second parameter is not a pointer to pointer to char,
    > >>>>>> >> but rather an array of pointers to char (or, more easily
    > >>>>>> >> understood, it is an array of pointers to strings). It should
    > >>>>>> >> be declared as char opt1[], not char **op1.
    > >>>
    > >>>>> >
    > >>>>> >To be pedantic ...
    > >>
    > >>>>
    > >>>> I don't think you actually said anything different than what
    > >>>> I did, except that you are applying the same terms to different
    > >>>> objects than I did.
    > >
    > >>
    > >>Ok, there's some truth in that. Let me explain my "terms" more fully:
    > >>
    > >>The formal parameter type is:
    > >> pointer to pointer to char
    >
    > If you mean the parameter list of the declaration, *look* at the
    > above declaration, which is "char * const argv[]". That is a
    > pointer to an array of pointers to char, not a pointer to
    > pointer to char. (I'm ignoring the "const" in this discussion
    > to reduce confusion.)
    You are nearly(*) correct in a sense. (Sadly I wandered into this
    discussion claiming to be pedantic, but haven't been pedantic enough in my
    explanations). The second parameter is declared as an array of pointer to
    char, but is immediately converted to a pointer to pointer to char. (I
    think we're agreed to ignore the "const" for this discussion!). The C99
    standard says:

    "A parameter declared to have array or function type is converted to a
    parameter with a pointer type as described in 6.9.1." [6.5.2.2]

    "A declaration of a parameter as 'array of type' shall be adjusted to
    'qualified pointer to type' ... " [6.7.5.3]

    "On entry to the function, the size expressions of each variably
    modified parameter are evaluated and the value of each argument
    expression is converted to the type of the corresponding parameter as if
    by assignment. (Array expressions and function designators as arguments
    were converted to pointers before the call.)" [6.9.1]

    So we see that:

    (1) The declaration of the parameter is converted from "array of pointer to
    char" to "pointer to pointer to char".

    (2) On calling the function, the actual argument, if of type "array of
    pointer to char", is converted to "pointer to pointer to char" before
    being passed.

    Indeed, if I look on my machine (vanilla RedHat 8.0), the man page has
    the second parameter as "char * const argv[]" (the same as you quoted),
    but in the system header files it is declared as:

    extern int getopt (int ___argc, char *const *___argv, const char *__shortopts);
    > >>>>> >Technically the second parameter *is* a pointer to (a const) pointer to
    > >>>>> >char.
    > >>
    > >>>>
    > >>>> Not in the prototype/declaration above!
    > >
    > >>
    > >>I disagree! It may look like it is, because it uses [], but really it's a
    >
    > Array types are distinct from pointer types. That really is an
    > array type, because it does use the [] syntax.
    True. What I said there wasn't strictly correct. (But see above).
    > Array objects and pointers objects are NOT the same thing.
    I agree!
    > >>Try passing an array of pointers to char into
    >
    > First, for the parameter list in a declaration, when comparing
    > functions for compatibility, yes the array type will first be
    > converted to a pointer type before determining if the types are
    > compatible.
    >
    > Second, when a function call is made, the argument list holds
    > the identifiers of objects listed, and that in this case would
    > include the name for an array object. However, before the
    > actual function call is made the identifier for the array object
    > will be converted to a pointer to the first element of that
    > object.
    >
    > None of which means that "really it's a pointer type, not an
    > array". It is an array, and in specific situations it is
    > specifically converted to a pointer.
    Ok, I concede that the formal parameter does have array type. But - it is
    converted into a pointer type before it can have any effect on a caller of
    the function.
    > I was being pedantic. :-)
    Argghhh - impaled on my own words :-)


    Perhaps I can try and summarise:

    1. I agree that you were correct in saying that:

    The formal parameter really does have array type.

    (And I was wrong to say that it *does have* pointer type)

    2. However, my contention is (and this is how I should have (pedantically!)
    explained it the first time):

    The formal parameter is converted to a pointer type, and therefore the
    array type declaration has no more effect than documenting that the
    function expects the pointer to access an array rather than a single
    object.

    This is why glibc can merrily document that it is an array type but
    really declare it as a pointer type.

    (*) I say "nearly", because you said "pointer to an array of pointers to
    char". If we're discussing exactly what the declared type is, then it's
    not a pointer type yet, but simply an "array of pointers to char".
    Of course, later on in the discussion you do say it's an array type, so
    I'll assume that's what you meant in this first instance.

    (Phew! :-)

    --
    Matthew Hails <matthew@hails.org.uk>

    Matthew Hails Guest

Posting Permissions

  • You may not post new threads
  • You may post replies
  • You may not post attachments
  • You may not edit your posts

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139