[sane-devel] [RFC] scanimage argument parsing bug

[Stef]

Hello,

I have ran into problems with scanimage argument parsing, at least with glibc-2.17,
any arguments other than defined in BASE_OPTSTRING isn't understood. For instance
scanimage -d $BACKEND --mode Color --width 50.0 --height 50.0 -t 20.0 -l 30.0 --batch=$RESULTS/$0-%d.pnm --batch-count=2 2>$RESULTS/$0.log

would give  unrecognized option '--batch=CanonLiDE354050/results/./batch001-%d.pnm'

I eventually found that the problem was related to setting optind to 0 line 2094 of scanimage.c .

In glibc sources there is the following comment:

* Index in ARGV of the next element to be scanned.
    This is used for communication to and from the caller
    and for communication between successive calls to `getopt'.

    On entry to `getopt', zero means this is the first call; initialize.

    When `getopt' returns -1, this is the index of the first of the
    non-option elements that the caller should itself scan.

    Otherwise, `optind' communicates from one call to the next
    how much of ARGV has been scanned so far.  */

/* 1003.2 says this must be 1 before any call.  */
int optind = 1;


So I am considering the following patch that fixes the argument parsing bug for me.

--- a/frontend/scanimage.c
+++ b/frontend/scanimage.c
@@ -2091,7 +2091,6 @@ Parameters are separated by a blank from single-character options (e.g.\n\
  
        /* re-run argument processing with backend-specific options included
         * this time, enable error printing and arg permutation */
-      optind = 0;
        opterr = 1;
        while ((ch = getopt_long (argc, argv, full_optstring, all_options,
                                 &index)) != EOF)


Has anyone also met this command line argument parsing problem ?
Would such patch be the correct thing to do, how optind should be treated ?

Regards,
	Stef