Re: $PATH bug?
>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Martin Buchholz writes:
> They used to live in the same directory, and the old code worked.
I
> veto changing PATH, since this is a user-controlled variable that we
> should avoid changing if at all possible.
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.
Sure we could have another way. For example, we could adopt another
environment variable EMACSPACKAGEBINPATH, and our scripts can invoke
other executables using the careful idiom
PATH="${PATH:-/usr/bin:/bin}${EMACSPACKAGEBINPATH:+:$EMACSPACKAGEBINPATH}"
other_executable
Do we actually have a documented standard about where in the package
hierarchy executables should go?
Martin