(Fwd) Re: getopts question

(Fwd) Re: getopts question

[Bart Schaefer]

The latest zsh 4.1.x from CVS, and 4.0.x, both print "1" for the test script
quoted below.  Apparently they should print "2".  Commentary?

--- Forwarded mail from David Korn <dgk@research.att.com>

Date: Tue, 15 Apr 2003 16:03:11 -0400 (EDT)
From: David Korn <dgk@research.att.com>
To: shell@research.att.com
Subject: Re: getopts question

Subject: Re: getopts question
--------

> What is the following script supposed to print if invoked as `foo -a'?
> 
> --- snip ---
> #!/bin/sh
> 
> while getopts : f
> do
>     case "$f" in
>     \?)  break;;
>     esac
> done
> 
> echo $OPTIND
> --- snip ---
> 
> On every version of bash but the most recent it printed 1.
> 
> On ash and pdksh it prints 1.
> 
> Chet tells me that 2 is the right thing to print, since recent
> versions of att-ksh print 2 and the posix manual says so.
> 
> This breaks historical practice and is a pain to detect. What's
> the rationale behind the change? I would assume since getopts
> actually did not parse something successfully, it should not
> increment $OPTIND?
> 
> christos
> 

This came up in 1995 when shell conformance tests were being
run on ksh, and I was forced to change the behavior then.

I tried to argue that the behavior was not specified, but  they
disputed my claim.  I have included some e-mail below.
It looks like we are stuck with 2 being the correct behavior.

>> getopts:
>>
>> A while back I had mentioned that some VSC getopts tests failed because
>> OPTIND wasn't incremented after reading a non-option.  The test writers
>> disputed my argument (based on your mail) that the behavior wasn't well
>> specified for error conditions.  They cited POSIX 4.27.2, lines 4631-4633
>> among the evidence that the behavior is specified.  After several exchanges
>> I was convinced by their arguments and made the following change to
>> optget() in libast/misc/optget.c:

Lines 4631-4633 state.
"Each time it is invoked, the getopts utility shall place the value of
the next option in the shell variable specified by the name operand and
the index of the next argument to be processed in the shell variable
OPTIND."

David Korn
research!dgk
dgk@research.att.com
____________________________________________________________
To unsubscribe from this list, please send the following
two-line message to majordomo@research.att.com, in which
your_email_address should be replaced by the address you
used when you subscribed to the list:
unsubscribe shell your_email_address
end


---End of forwarded mail from David Korn <dgk@research.att.com>

Re: (Fwd) Re: getopts question

[Peter Stephenson]

"Bart Schaefer" wrote:
> The latest zsh 4.1.x from CVS, and 4.0.x, both print "1" for the test script
> quoted below.  Apparently they should print "2".  Commentary?

Go ahead and change it if you like, I think it's rare enough it won't
screw up too much.  You can argue for 2 from the existing zsh
documentation.

Note, however, that changing the handling of option indexes by tradition
always introduces bugs.  At least, I'm pretty sure I've fixed it about
three times.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************