[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible getopts bug
From: |
Chet Ramey |
Subject: |
Re: Possible getopts bug |
Date: |
Mon, 26 Nov 2001 14:30:16 -0500 |
> $ cat bashbug2
> #!/bin/bash
>
> set -- -ab arg1
> echo -e "Initial Value of OPTIND: $OPTIND\n"
> while getopts ab optname
> do
> echo "Option: $optname OPTIND: $OPTIND"
> done
> ./bashbug2
> Initial Value of OPTIND: 1
>
> Option: a OPTIND: 1
> Option: b OPTIND: 2
> $
>
> Notice in the above that, for purposes of incrementing OPTIND,
> getopts seems to improperly treat the two options as a single
> option. Put differently, it would seem that the value placed
> into OPTIND shouldn't depend on whether options are combined
> following a single introductory - or expressed separately. Am
> I missing something?
This is correct behavior.
First, getopts is not treating the two options as one: it returns both
options separately. I don't think there is any argument here.
OPTIND is supposed to be the index (into $@, essentially) of the
argument getopts is processing. After parsing option a, getopts
is still working on $1, so OPTIND is still set to 1. After it
parses b, it moves on to $2 (`arg1'), and sets OPTIND appropriately.
OPTIND is not supposed to be a count of the number of single-
character options that getopts has returned; if you want that
count, you must maintain it yourself.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)
Chet Ramey, CWRU chet@po.CWRU.Edu http://cnswww.cns.cwru.edu/~chet/