Re: [PATCH] Avoid bug in Solaris xpg4/sed as used in submodule

Andreas Schwab [off-list ref] writes:

Ben Walton [off-list ref] writes:

quoted

Excerpts from Andreas Schwab's message of Mon Apr 09 02:40:03 -0400 2012:

quoted

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.