From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Wed, 06 May 2009 23:07:00 GMT
Subject: Re: shell compatibility issues with SunOS 5.10
Message-ID: <fcaeb9bf0905061607n51457fa3x3a198c61911d0228@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0905061137300.14230@intel-tinevez-2-302>

On Wed, May 6, 2009 at 7:38 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 6 May 2009, Ralf Wildenhues wrote:
>
>> Nguyen Thai Ngoc Duy writes:
>> > On Wed, May 6, 2009 at 4:45 PM, Johannes Sixt wrote:
>> > > Nguyen Thai Ngoc Duy schrieb:
>> > >>       # normalize path:
>> > >>       # multiple //; leading ./; /./; /../; trailing /
>> > >>       path=$(printf '%s/\n' "$path" |
>> > >>               sed -e '
>> > >>                       s|//*|/|g
>> > >>                       s|^\(\./\)*||
>> > >>                       s|/\./|/|g
>> > >>                       :start
>> > >>                       s|\([^/]*\)/\.\./||
>> > >>                       tstart
>> > >>                       s|/*$||
>> > >>               ')
>>
>> > It says nothing. The result of "printf '%s\n' ./foo/bar | sed -e blah"
>> > is just wrong, (i.e. "./" remains). I stripped down to "sed -e
>> > 's|^\(\./\)*||'", does not work. Probably due to \( \) pair. Skimmed
>> > through sed manpage, seems no mention of bracket grouping.
>>
>> Quoting 'info Autoconf "Limitation of Usual Tools"':
>>
>>      Some `sed' implementations, e.g., Solaris, restrict the special
>>      role of the asterisk to one-character regular expressions.  This
>>      may lead to unexpected behavior:
>>
>>           $ echo '1*23*4' | /usr/bin/sed 's/\(.\)*/x/g'
>>           x2x4
>>           $ echo '1*23*4' | /usr/xpg4/bin/sed 's/\(.\)*/x/g'
>>           x
>>
>> You can work around it in this case with
>>   :again
>>   s|^\./||
>>   t again
>>
>> BTW, you should put a space between t and the label (but not between
>> : and label), POSIX requires that and some sed versions expect it.
>
> Maybe the time is better spent on turning submodule into a builtin, before
> it gets even larger, and before we have to jump through even more hoops
> because of shell compatibility issues?

Totally agree. git-submodule is the second largest shell script.
Better do it now or it will take git-rebase--interactive position as
the biggest one.
-- 
Duy