Andreas Schwab <schwab@xxxxxxxxxxxxxx> writes:
> Ben Walton <bwalton@xxxxxxxxxxxxxxxxxx> writes:
>
>> Excerpts from Andreas Schwab's message of Mon Apr 09 02:40:03 -0400 2012:
>>
>>> How about using 's|[^/][^/]*|..|g' instead, which should avoid the bug
>>> as well.
>>
>> I'd be ok with that change if the changed semantics of the regex are
>> ok in this application. It's essentially the same as s|[^/]+|..|g,
>> which requires at least one character.
>>
>> In the current code, if you do:
>>
>> echo '/' | sed -e 's|[^]*|..|g'
>>
>> you get: ../.. (from a working implementation).
>>
>> Your regex would see the result be: /
>>
>> I don't think we'd ever be passing a plain /, but we might pass a
>> fully qualified path /path/to/foo, which would see the result change
>> from ../../../.. to /../../.. and that could have unintended impact.
>
> AFAICS the variables at this point never contain a value with a leading
> slash.
Correct. After $a and $b are initialized to "$(cd somewhere ; pwd)/",
there is a loop:
while test "${a%%/*}" = "${b%%/*}"
do
a=${a#*/}
b=${b#*/}
done
The test for the first iteration will see that they both start with '/' so
stripping maximal trailing substring that match "/*" from them will yield
two empty strings, and we always enter the body of the loop. The body
during the first iteration will strip the leading '/'.
When pwd computed for both $a and $b were at '/', this loop may do
something funky ($b will become empty), but that is covered by an earlier
"is $a inside $b or vice versa?" check, so we should be OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html