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. I'd need to look more closely to see if this is a problem in reality. Others more familiar with this code likely know the answer already. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -- 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