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

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 25.02.2009 22:25:
> 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.

I'm a bit confused now. Are you saying that "git-submodule.sh" should
avoid the multiple lines in sed (which work in AIX 4.3.3)? I don't know
how to simplify a/b/c/../../ easily then. Of course one could loop
around in shell rather than using sed's "goto", but that looks ugly.

I think that's my only question before doing a v3 which will be a good
"cd citizen" in tests and test for more idiosyncracies.

Oh wait: Would it be worthwhile to have that shell version of
normalize_path_copy() in git-sh-setup instead?

Michael