Re: Is this an IFS bug in getopts?

[DJ Mills]

On Tue, Apr 26, 2011 at 11:42 AM, Steven W. Orr <steveo@syslang.net> wrote:

> GNU bash, version 4.0.35(1)-release (x86_64-redhat-linux-gnu)
>
> I ran a program that was supposed to die with an error message that said:
>
> Invalid format: example: 2.103.269.28-1-3
>
> Instead, it died with:
>
> i -- Invalid format: example: 2.103.269.28-1-3
>
> I traced the problem back to a call to getopts. It turns out that when I
> called getopts, I had set IFS='-'. It never occurred to me that I could
> impact the function of getopts by setting IFS.
>
> The old code was this:
> DRVREV="$1"
> IFS=-
> set -- $DRVREV
> (( $# == 3 )) || die -i -- 'Invalid format: example: 2.103.269.28-1-3'
>
> I can fix the problem easily by saying
>
> oldIFS="$IFS"
> DRVREV="$1"
> IFS=-
> set -- $DRVREV
> IFS="$oldIFS"
> (( $# == 3 )) || die -i -- 'Invalid format: example: 2.103.269.28-1-3'
>
> So here we are.
> 1. Should getopts be documented to say that it uses IFS?
> 2. Should getopts be hardcoded to use the dash as the option delimiter?
> 3. Is the current functionality correct the way it is and I'm just looking
> at it wrong?
>
> TIA :-)
>
> --
> Time flies like the wind. Fruit flies like a banana. Stranger things have
>  .0.
> happened but none stranger than this. Does your driver's license say Organ
> ..0
> Donor?Black holes are where God divided by zero. Listen to me! We are all-
> 000
> individuals! What if this weren't a hypothetical question?
> steveo at syslang.net
>
>
 I don't see getopts anywhere in that example.  It would also help to know
what your
die() function is, as I suspect that may be causing the issue.