Re: [PATCH] Add an XSI replacement for func_split_short_opt.

[Gary V. Vaughan]

Hi Eric,

Thanks for the feedback!

On 29 Jun 2010, at 05:37, Eric Blake wrote:
> On 06/28/2010 04:19 PM, Ralf Wildenhues wrote:
>> * Eric Blake wrote on Mon, Jun 28, 2010 at 02:49:40PM CEST:
>>> tmp=${1#?}
>>> patt=
>>> i=2
>>> while test $i -lt ${#1}; do
>>>  patt="?$patt"
>> 
>> If the parameter may be expected to be very long (which I don't think it
>> will be) then
>>  func_append patt '?'
>> 
>> would be useful here, and even if not, appending rather than prepending
>> here helps with current bash.
>> 
>>>  i=$((i+1))

I think we can't rely on the availability of $((expr)) :(

>>> done
>>> result=${tmp%$patt}
> 
> After thinking a bit more, this alternative should do the same job in
> fewer lines of code and fewer temporary variables:
> 
> result=${1#?}
> while test ${#result} -gt 1; do
>  result=${result%?}
> done
> 
> Also, you have to be a bit careful:
> $ tmp=a
> $ echo ${tmp:2}
> 
> $ echo ${tmp#??}
> a
> 
> that is, before trying to split off the first two bytes using XSI, you
> must ensure that ${#1} has at least two bytes to be split in the first
> place.

Well, really the problem is this:

while $# -gt 0; do
  opt=$1; shift
  case $opt in
    -p) opt_p="$1"; shift ;;
    -q) opt_q="$1"; shift ;;
    -x) opt_x=: ;;
    -y) opt_y=: ;;

    -p*|-q*) # option args
        func_split_short_arg $opt
        set dummy $arg "$rest" ${1+"$@"}; shift ;;

    -x*|-y*) # non-option args
        func_split_short_arg $opt
        set dummy $arg -$rest ${1+"$@"}; shift ;;
  esac
done

So, we know there will always be at least 3 characters available in $1
by the time we reach func_split_short_arg.  Also we don't really discard
the leading '-'.  Which means that this works correctly:

func_split_short_arg ()
{
  arg="$1"; while test ${#arg} -gt 2; do arg="${arg%?}"; done
  rest=${1%??}
}

However, I think that will be considerably slower than the ${1:0:2}/${1:2}
approach.  But we're probably talking microseconds... so I'm open to
advice on whether to use bash/ksh variable substrings exclusively (as per
current master); XSI exclusively (although we make heavy use of += already
if it is available, so not really exclusively); or to prefer substring
syntax over the XSI syntax if either or both are available, falling back
on sed if necessary?

We also need to keep in mind that we plan to migrate at least the core of
the option processing code generation into Autoconf after 2.66, and I
haven't yet figured out how to generalize the function substitution to
apply to all M4SH_GETOPTS clients when that happens (Libtool master
currently hardcodes just the libtool script for function substitution,
with everything else using just the sed fallback implementations).

Cheers,
-- 
Gary V. Vaughan (address@hidden)