[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GUILE_LOAD_PATH and the UNIX architecture
From: |
Matt Wette |
Subject: |
GUILE_LOAD_PATH and the UNIX architecture |
Date: |
Mon, 20 Jul 2015 17:46:40 -0700 |
Hi Folks,
I have found another issue with the GUILE_LOAD_PATH. In January I filed a bug
report (#19540) on the use of "." in GUILE_LOAD_PATH. Now I'm running into
another issue with GUILE_LOAD_PATH that contains an empty path (e.g.,
"/x::/y"). Before I file a bug report I wanted to see if there is a consensus
on what the behavior of guile should be in these cases.
The convention in Unix-based systems is that environment PATH variables provide
users a way to alter the set of directories searched for resources. Now "."
(and other relative paths) are allowed in most, if not all, the path-sensitive
applications I am aware of. It is now conventional wisdom that "." in the PATH
variable can be dangerous, but nonetheless this is allowed: it is up to the
user to set up things intelligently: it is part of the UNIX architecture.
Occasionally, I like to add "." to some path environment variables to help
development, debugging etc.
So should guile work with "." in the PATH or not, and if not, should it import
that into %load-path? And if it does, what should the behavior be?
Now here are the features, or bugs if you prefer, that I have found:
1) if you put "." in GUILE_LOAD_PATH, then the path loaded in complied modules
gets loaded with "././././././" (one "./" added each time the module is
recompiled).
2) if you put the empty path ("/x::/y") in GUILE_LOAD_PATH (two colons with
nothing between), the behavior of `(include "file")' does not work.
Comments?
Matt
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- GUILE_LOAD_PATH and the UNIX architecture,
Matt Wette <=