Junio C Hamano venit, vidit, dixit 03.03.2009 16:36: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > >> Michael J Gruber schrieb: >>> + # normalize path: >>> + # multiple //; leading ./; /./; /../; trailing / >>> + path=$(printf '%s/\n' "$path" | >>> + sed -e ' >>> + s|//*|/|g >>> + s|^\(\./\)*|| >>> + s|/\./|/|g >>> + :start >>> + s|\([^/]*\)/\.\./||g >> Sorry to say: not yet. This turns "a/b/c/d/../../../d" into "a/b/c/d" >> instead of "a/d". Drop the 'g'. >> >> Once this is fixed, I have to ask what should happen with path names like >> "../a/b", "../../a/b"? Should there be a warning or error? >> >> Other than that, this expression works on AIX 4.3.3! Note in particular >> that '\n' in the printf format string is essential! >> >>> + tstart >>> + s|/*$|| >>> + ') > > At some point you should wonder if all of this complication is worth it, > or it makes sense to reject when you see // or /\.\./ in the input. I surely do wonder now! This started off treating merely leading ./ as reported problematic by AT. Then the "do it really right" competition started, and I think J6t and I came out as clear winners. There were no other contenders. Seriously, "git submodule init" does that normalization (by using ls-files), so I think it does make sense to have it for add as well. git submodule itself may have semi-porc/semi-plumb character, but if someone wants to add submodules programmatically there is no simple way around using "git submodule add", and paths may very well be constructed relatively. Michael -- 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
