Eygene Ryabinkin <rea-git@xxxxxxxxxxx> writes: > Wed, Mar 28, 2007 at 12:48:45PM -0700, Junio C Hamano wrote: >> Eygene Ryabinkin <rea-git@xxxxxxxxxxx> writes: >> ... >> > +gitk-wish: gitk GIT-GUI-VARS >> > + $(QUIET_GEN)rm -f $@ $@+ && \ >> > + sed -e'1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' < gitk > $@+ && \ >> > + chmod +x $@+ && \ >> > + mv -f $@+ $@ >> ... > Thanks! And for the sanity: I do not think that the single quote > in the path it sane too. But as I was teached, "if we should > quote something, we must quote it". ;)) Actually, look at the wish script you are running sed on. exec wish "$0" -- "$@" If you substitute "wish" with "/i use stupid/$PATH/to/wish", I think Tcl splits the path at SP and does not protect $var reference, so the careful quoting in the Makefile is still not good enough ;-). But come to think of it, it lets shell handle $PATH to find wish anyway, so *unless* we have specific version dependency to wish that wish binary normally found on user's $PATH is inadequate, we probably should not even need to be doing any of this path munging. You might end up discovering the path to wish binary in your autoconf script, we do not have to use it. ./configure can just see if there is wish, and set NO_TCLTK appropriately without any of the path business. What do you think? > By the way, when I was creating the git.spec from the git.spec.in, > I had the 'Version' field equal to the '1.5.1-rc1.GIT' and RPM > does not like the '-' characters inside the versions. That is semi-intended, in that you are not even supposed to be building with "1.5.1-rc1.GIT". The version file in the tarball that git.spec file lives in should use git-describe, built from the source before the tarball was made, to get the version number, and wouldn't be "$anything.GIT", which is the last-ditch fallback string, which is set by GIT-VERSION-GEN for people who build in a wrong way. - 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