[Top][All Lists]

[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 
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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]