From bug-octave-request at bevo dot che dot wisc dot edu Fri Oct 23 14:07:54 1998 Subject: Re: [patch] extra colon feature + problem with default loadpath From: Rafael Laboissiere To: bug-octave at bevo dot che dot wisc dot edu Date: Fri, 23 Oct 1998 14:07:31 -0500 (CDT) [I just realized that the original message in this thread probably did not appear on the bug-octave mailing list or in the archive because Rafael is not on the list, so his message was not posted automatically and I forgot to forward it. --jwe] Hi John, Thanks for your reply. I understand that my patch introduces many undesirable modifications in the octave source. In an afterthought, I find that some of the modifications are really inappropriate (like introducing Vload_path_default in liboctave). However, some features that I introduced (LOADPATH starting up with ":", hiding the default path, as well as the expansion of doubled colon, but for sure not that infamous misunderstanding about OCTAVE_PATH) should be considered for next releases. Comments on your message: >>>>> "JWE" == John W Eaton writes: JWE> It also assumes that the dir_path class is only going to be JWE> used to expand LOADPATH, but it is also used to search files in JWE> other PATH-like variables. Automatically inserting the value JWE> of Vload_path_default in them is probably not right. Why not? Remember that Vload_path_default is inserted only for extra colons. If the user asks (notice the colon): file_in_path(":/foo//", "bar") she is explicitly asking for search in the default path. OTOH, if she asks: file_in_path("/foo//", "bar") the method dir_path::find() will _not_ insert the default path. JWE> | A new builtin function JWE> | Fload_path_default() was also created, which prints the default path JWE> | (this addition is fully optional, but is the only way that I could JWE> | imagine to get access to the value of the default path from the Octave JWE> | prompt). JWE> It would have also been possible to define a new built-in variable JWE> using DEFVAR. Right. I did not know about DEFVAR. JWE> | The default value for Vload_path (and hence LOADPATH at startup) is set JWE> [...] JWE> I'm getting a bit confused here. Sorry, my explanation is a little bit confusing. But this point is not very important, anyway. JWE> | First, the bug: the environment variable OCTAVE_PATH, if it exists, is JWE> | intended to replace the default path (defined by #define JWE> | OCTAVE_FCNFILEPATH). JWE> I think there is some misunderstanding here. OCTAVE_PATH is not JWE> intended to provide a way to override the value of OCTAVE_FCNFILEPATH. JWE> It is just intended to be another way to specify the default value of JWE> LOADPATH from the environment. Okay, I misunderstood that (I had better RTFM :-). I think that the origin of my misunderstanding is that I thought that overriding the default path would be a good thing. Currently, there is no way to do that. Conversely, there are three ways of changing the LOADPATH: (1) by setting its value in a script, (2) with option --path, and (3) with env var OCTAVE_PATH. Should we define a new environment variable OCTAVE_DEFAULT_PATH? JWE> Keeping the default path hidden may seem like a nice feature, but it JWE> will cause problems for things like this: JWE> file_in_path (LOADPATH, "foo") JWE> because file_in_path doesn't know that LOADPATH is special, so it JWE> can't know to insert the default path at the appropriate places. See my comment above. What I did not understand is that the command above does not work in my modified version (it should work, as dir_path inserts always the default path at appropriate places). Maybe I introduced a bug with my patch. I will check this. Regards, -- Rafael Laboissiere Institut de la Communication Parlee | Email: rafael at icp dot inpg dot fr UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael