Re: libseed-list imports.searchPath

["Alan Knowles" <alan akbkhome com>]

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 ;)

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


your patch would be a little clearer just changing push() to unshift(), eg.
imports.searchPath.unshift( __script_path__ );
imports.searchPath.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     

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