GUILE_LOAD_PATH and the UNIX architecture

GUILE_LOAD_PATH and the UNIX architecture

[Matt Wette]

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