Re: $PATH bug?

Kyle> Martin Buchholz writes: Kyle> I don't see how we're going to avoid changing it and still have Kyle> packaged executables be able to execute other packaged executables. Kyle> We're talking about modifying PATH for subprocesses of XEmacs. Kyle> Adding package lib-src directories to PATH makes sense in this Kyle> context, just as modifying TERM makes sense in the content of M-x Kyle> shell and M-x terminal-emulator. I can't see how a package Kyle> author would solve the configuration problem that will Kyle> result if PATH isn't modified. Martin> Sure we could have another way. For example, we could adopt another Martin> environment variable EMACSPACKAGEBINPATH, and our scripts can invoke Martin> other executables using the careful idiom Martin> PATH="${PATH:-/usr/bin:/bin}${EMACSPACKAGEBINPATH:+:$EMACSPACKAGEBINPATH}" other_executable Martin> Do we actually have a documented standard about where in the package Martin> hierarchy executables should go? Martin is absolutely right. In fact, there was a thread on this very same question quite a while ago which sort of died. In fact, the package binaries should not even be appended to EXEC-PATH. If a package wants a binary, it should know what directory to look in, rather than looking in a semi-random global path which might actually include another binary with the same name in front of it. mmencode is a prominent example, where we've avoided problems in the past merely by virtue of the fact that Metamail hasn't changed recently. I intend to hack this in the next Great Path Overhaul which I'll get to once 21.0 is out. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla