GNOME.org
 

Re: libseed-list imports.searchPath

Alan Knowles wrote:

Looking at the code, I'm not sure what the behavour of '.' at the end
of the searchPath actually does (it calls g_dir_open() which I would
expect results in getcwd(), Current working directory. Which is
probably not the most desired situation. ( the old DOS virus problem
;)
Yes, I'm quite sure '.' means it will search the current working directory. This is probably not often needed. If someone really needs to do stuff like this: 

var os = imports.os;
var savedir = os.getcwd();
os.chdir(somedir);
var m = imports.mymodule;
os.chdir(savedir);

then it's probably better to just add somedir to imports.searchPath.


I know in PHP that '.' in the search path means path of current file
(rather than initial script or cwd) - I'm guessing python etc. are
the same.?


I see, that's probably much better.


your patch would be a little clearer just changing push() to
unshift(), eg. imports.searchPath.unshift( __script_path__ ); imports.searchPath.unshift("."); 

You're right, I had forgotten about unshift().


for the importer you could try changing the
seed-importer.c:seed_importer_search

from dir = g_dir_open ((gchar *) walk->data, 0, &e);
to something like this. gchar* sp = seed_value_to_string (ctx, seed_object_get_property (nctx, global, "__script_path__"); exception); 

gchar* test_path = (gchar *) walk->data; if (strcmp(test_path, ".")
== 0) { test_path = sp; }

And see how it behaves. Regards Alan


Ok, will try something out.

/Jonatan


--- On 17/Jun/2010, Jonatan Liljedahl wrote:

At the end of Seed.js, the code below will put the current script
path at the start of imports.searchPath. But to get the current
module's path there one will need to adjust the importer C code.
A much better approach would probably be to let seed_importer_get_search_path() return __script_path__ + 
searchPath, then it will work for the toplevel script as well as
all modules. Should I make a patch for this?
if(!imports.searchPath || (imports.searchPath.length == 0)) { imports.searchPath = [ "/usr/share/gnome-js", "/usr/lib/seed", "/usr/share/seed", "/usr/local/lib/seed", "/usr/local/share/seed", "/usr/lib/seed", "/usr/share/seed"]; 

if(Seed.argv.length > 1) { __script_path__ =
GLib.path_get_dirname(Seed.argv[1]); try { if(!GLib.path_is_absolute(__script_path__)) { __script_path__ = GLib.build_filenamev([GLib.get_current_dir(), __script_path__]); }
__script_path__ = imports.os.realpath(__script_path__); if(__script_path__ && __script_path__ != "") imports.searchPath = [__script_path__].concat(imports.searchPath); } catch(e) { print(imports.JSON.stringify(e)); } } imports.searchPath.push("."); 
 }

Alan Knowles wrote:

I think that would be a good idea, Once thing that I've found is
that restructuring an application by renaming directories, or
moving stuff around would be a little simpler if we allowed this.


I have code in JSDOC/Instrospect - which should really be moved
out of JSDOC subfolder, but since all the code inside that
directory does imports.JSDOC.Instrospect..... (and the use case
for that library is only about one file). the biggest effect of
moving the directory is changing the code it'self rather than the
use cases...

Regards Alan

--- On 17/Jun/2010, Jonatan Liljedahl wrote:

Tim Horton wrote:

At least in $PATH, the current directory isn't put first for
security reasons (if you're in a publicly writable directory,
you don't want malicious users putting their own copy of --
for example -- 'ls' in that directory and having that
unknowingly run by you when you're in that directory).

I'm going to go with "that's by design". Or at least, by
copying other people's design. It's not clear it matters as
much here.

Ok, I can see the point of that.


There's no reason the directory of the currently running
script couldn't be first, though. I think. I don't know :-)

That would be very good, I think!

Also perhaps adding a modules path at the beginning while
importing a module?

say you have foo/Foo.js, foo/Bar.js and in Foo.js you do
"b=imports.Bar" and you know that it will use the one in the
same directory. In a security point of view, if we *don't* do
this, then an evil user might alter imports.searchPath so it
uses their evil version of Bar.js instead, etc..

/Jonatan


On Wed, Jun 16, 2010 at 09:14, Jonatan Liljedahl
<lijon kymatica com> wrote:


I see. But looking at imports.searchPath it has automatic
added entries for the home path of the running script and
the current directory, but these are added at the end.
Shouldn't they be added to the beginning?


Tim Horton wrote:


No, we iterate over it in order (from first to last) as
far as I remember, just like $PATH. If you want your
stuff to get found first, prepend it to searchPath,
again, just like $PATH.

Could be wrong, it's been a while...

On 2010.06.16, at 06:37, Jonatan Liljedahl wrote:

In what direction is imports.searchPath searched? I guess
it should start

from the last one added? So that any custom paths are
searched before system ones..
/Jonatan _______________________________________________ libseed-list mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list
_______________________________________________ libseed-list mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list 


_______________________________________________ libseed-list
mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list 
_______________________________________________ libseed-list
mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list 
_______________________________________________ libseed-list
mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list 

_______________________________________________ libseed-list mailing
list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]