On Wed, May 6, 2009 at 7:38 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Wed, 6 May 2009, Ralf Wildenhues wrote: > >> Nguyen Thai Ngoc Duy writes: >> > On Wed, May 6, 2009 at 4:45 PM, Johannes Sixt wrote: >> > > Nguyen Thai Ngoc Duy schrieb: >> > >> # normalize path: >> > >> # multiple //; leading ./; /./; /../; trailing / >> > >> path=$(printf '%s/\n' "$path" | >> > >> sed -e ' >> > >> s|//*|/|g >> > >> s|^\(\./\)*|| >> > >> s|/\./|/|g >> > >> :start >> > >> s|\([^/]*\)/\.\./|| >> > >> tstart >> > >> s|/*$|| >> > >> ') >> >> > It says nothing. The result of "printf '%s\n' ./foo/bar | sed -e blah" >> > is just wrong, (i.e. "./" remains). I stripped down to "sed -e >> > 's|^\(\./\)*||'", does not work. Probably due to \( \) pair. Skimmed >> > through sed manpage, seems no mention of bracket grouping. >> >> Quoting 'info Autoconf "Limitation of Usual Tools"': >> >> Some `sed' implementations, e.g., Solaris, restrict the special >> role of the asterisk to one-character regular expressions. This >> may lead to unexpected behavior: >> >> $ echo '1*23*4' | /usr/bin/sed 's/\(.\)*/x/g' >> x2x4 >> $ echo '1*23*4' | /usr/xpg4/bin/sed 's/\(.\)*/x/g' >> x >> >> You can work around it in this case with >> :again >> s|^\./|| >> t again >> >> BTW, you should put a space between t and the label (but not between >> : and label), POSIX requires that and some sed versions expect it. > > Maybe the time is better spent on turning submodule into a builtin, before > it gets even larger, and before we have to jump through even more hoops > because of shell compatibility issues? Totally agree. git-submodule is the second largest shell script. Better do it now or it will take git-rebase--interactive position as the biggest one. -- Duy -- 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