[sane-devel] [RFC] scanimage argument parsing bug
stef.dev at free.fr
Wed Jun 5 19:09:39 UTC 2013
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.
@@ -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 ?
More information about the sane-devel