Markus Neteler wrote: > >> GRASS 7.0.svn (nc_spm_08): > sh i.fusion.his > >> sh: i.fusion.his: command not found > > > > Does it have the execute bit set? > > Yes. > > > If it doesn't, g.parser can't > > execute it. That has always been the case; it isn't specific to 7.0. > > ls -la i.fusion.his > -rwxr-xr-x 1 neteler neteler 3867 2009-09-29 21:36 i.fusion.his* > > The problem was that it wasn't in the search path.
I thought of mentioning this, then concluded that it shouldn't make a difference. But it turns out that it matters if GRASS_GUI is set to "wxpython". If you "execute" a script by typing its name, it must be in $PATH. But if you execute "sh" with the script filename as an argument, the shell will just [f]open() it, and the normal rules apply (i.e. any path not starting with a "/" is relative to the current directory). And when g.parser invokes the script, it uses execl(), which doesn't use the path. AFAICT, the problem is when g.parser uses G_gui_wx(). Whereas G_gui_tcltk() invokes gui.tcl and feeds it a description on its stdin, G_gui_wx() invokes menuform.py with the command line, and G_gui_wx() re-invokes the script with the --interface-description flag. The script is exceuted using os.popen(), which uses /bin/sh, which uses $PATH, hence the error. So if you run the script with arguments (so that no dialog is generated), or if GRASS_GUI is set to "tcltk", I think that it should work regardless of whether the script is in $PATH. -- Glynn Clements <[email protected]> _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
