Re: [PATCHv2 4/4] git submodule: Fix handling of // and /.. in paths for added submodules

> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> Michael J Gruber schrieb:
>>> Johannes Sixt venit, vidit, dixit 25.02.2009 15:06:
>>>> I think we have so far avoided \+ in sed expressions for portability reasons.
>>> Hmmpf. Is it that new, or gnu specific? I'm always afraid of portability
>>> issues with bash but wasn't aware of sed being an issue as well.
>>>
>>> In any case, would 's|\\*|/|g' be better (more portable) then?
>> You mean 's|//*|/|g'; yes, that is definitly portable.
>>
>>> Well, how is
>>>
>>> echo a/b/c/../../d | sed -e ':start;s|\([^/]*\)/\.\./||g;tstart'
>>> a/d
>>>
>>> I meant: how portable is...
>> I don't know... Let's see: My AIX 4.3.3 sed understands it if it is not
>> all on a single line, and that says a lot. Specifically, I tried this:
>>
>> echo a/b/c/../../d | sed -e ':start
>>              s|\([^/]*\)/\.\./||
>>              tstart
>> '
>>
>> and got the desired result:
>>
>> a/d
>>
>> Note that the 'g' flag is not necessary in this case.
>>
>> OTOH, this sed doesn't understand #comments :-/
> 
> Historically, sed was much worse than the shell when it came to the
> portability issues, especially before people started to use bash, which
> tipped the balance a bit by worsening the situation for the shell side.
> 
> The sed scripts in the more important parts of scripted Porcelains avoid
> multiple commands on a single line concatenated with ";" mostly by inertia
> on my side, but it was acquired exactly from this kind of portability
> mess.  IIRC, AIX's was the worst offender. It also got "/A/../B/ { ... }"
> wrong in earlier versions.