2:12 a.m.
Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org:
>>>>> "SL" == SL Baur
<steve(a)xemacs.org> writes:
...
SL> Shouldn't lib-src directories also get appended to $PATH? It makes
SL> the above problem go away.
No.
The dot files for the shell could just re-munge your PATH back
anyways.
That's not a case I'm concerned about. The user is always allowed to
shoot himself in the foot and it isn't our problem.
A Posix shell looks for $ENV.
I tried to solve this problem in the distant past by adding this
hack
to all the scripts in lib-src:
PATH=${PATH:-/usr/bin:/bin}:`dirname $0 2>/dev/null`; export PATH
This hack requires that $0 contain the full path to the script, and
that dirname exists. Why would this this not be the case?
This doesn't solve the right problem.
In the case I'm citing, tmdecode and mmencode don't live in the same
directory. tmdecode lives in the xemacs-packages lib-src directory,
and mmencode lives in the XEmacs core lib-src directory. Taking the
full path to tmdecode is not going to help one bit about finding
mmencode[1]. Both need to be exported via $PATH, IMO.
Footnotes:
[1] Which shouldn't be included with XEmacs anyway, but here we are.
2:23 a.m.
New subject: $PATH bug?
>>>> "SL" == SL Baur <steve(a)xemacs.org>
writes:
SL> Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org:
>>>>>> "SL" == SL Baur
<steve(a)xemacs.org> writes:
SL> ...
SL> Shouldn't lib-src directories also get appended to $PATH? It makes
SL> the above problem go away.
> No.
> The dot files for the shell could just re-munge your PATH back
> anyways.
SL> That's not a case I'm concerned about. The user is always allowed to
SL> shoot himself in the foot and it isn't our problem.
> A Posix shell looks for $ENV.
> I tried to solve this problem in the distant past by adding this
hack
> to all the scripts in lib-src:
> PATH=${PATH:-/usr/bin:/bin}:`dirname $0 2>/dev/null`; export
PATH
> This hack requires that $0 contain the full path to the script,
and
> that dirname exists. Why would this this not be the case?
SL> This doesn't solve the right problem.
SL> In the case I'm citing, tmdecode and mmencode don't live in the same
SL> directory. tmdecode lives in the xemacs-packages lib-src directory,
SL> and mmencode lives in the XEmacs core lib-src directory. Taking the
SL> full path to tmdecode is not going to help one bit about finding
SL> mmencode[1]. Both need to be exported via $PATH, IMO.
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. Please find some other way
to solve this problem, especially given that the directory
reorganization initiative has broken this.
Observe also that the old code would invoke the user's mmencode, if
installed earlier in the user's PATH. Presumably he would want that
one invoked.
Martin
6:14 a.m.
New subject: $PATH bug?
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.
I don't see how we're going to avoid changing it and still have
packaged executables be able to execute other packaged executables.
We're talking about modifying PATH for subprocesses of XEmacs.
Adding package lib-src directories to PATH makes sense in this
context, just as modifying TERM makes sense in the content of M-x
shell and M-x terminal-emulator. I can't see how a package
author would solve the configuration problem that will
result if PATH isn't modified.
Observe also that the old code would invoke the user's mmencode,
if
installed earlier in the user's PATH. Presumably he would want that
one invoked.
True, but Steven suggested appeneding to PATH, which would allow
the override.
6:38 a.m.
New subject: $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
9409
days inactive
9409
days old
3 comments
3 participants
participants (3)
-
Kyle Jones -
Martin Buchholz -
SL Baur