[GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
GRASS GIS
trac at osgeo.org
Sun Jun 23 12:57:17 PDT 2013
#2008: grass.script's find_program() can't find modules
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python | Version: svn-releasebranch64
Resolution: | Keywords: find_program()
Platform: All | Cpu: x86-64
-----------------------+----------------------------------------------------
Comment(by wenzeslaus):
== find_program ==
Replying to [comment:31 hamish]:
> Replying to [comment:29 wenzeslaus]:
> > It could be convenient (for both the interface and implementation) to
> > have special function to test presents of GRASS modules.
>
> just to note that the last version of that I saw failed to pick up Addon
modules.
> (installed in either the GRASS_ADDON_PATH(s) &/or ~/bin/)
>
Did you test r56869? To be honest, I never remember if `GRASS_ADDON_PATH`
is in `PATH`. If it is not in `PATH`, `find_program` (`test/run_program`)
probably not work for addons. Maybe another reason for creating new
function for modules. We can even call it `is_module_present/here` to
create nicely readable code. You can provide your suggestions, especially
those English-correct. The implementation is clear: same as current
(glynn's) `find_program` (run the module), `help` parameter added and all
GRASS acceptable paths used.
== test in g.manual ==
Replying to [comment:30 hamish]:
> Replying to [comment:29 wenzeslaus]:
> > Anyway, in r56880 I have deleted the test in g.manual since I
> > don't see any reason for it.
>
> In r56882 I have put it back. It is nice to have the clearer error
message on Linux (where the error could come up a lot), and in cases where
GRASS_HTML_BROWSER is either unset of malformed. It may need to be
improved or fixed, but it should be there.
>
Tell me examples, please. I don't see much difference between "''Browser
'%s' not found''" and "''Error starting browser '%(browser)s' for HTML
file '%(path)s'''".
Since the test (`find_program`) does not work for clear examples such as
`firefox`, I don't see the reason to keep the test there to produce just
slightly better error message in other cases (moreover, the meaning of the
message is absolutely clear only if you know, which function/test caused
this message, IMHO).
Anyway, if you think that the test is necessary, we can use the
`shutil.which` function to do the test. Thus, we will have two functions,
as already proposed by annakrat in comment:25.
== opening HTML page ==
Replying to [comment:32 glynn]:
> Replying to [comment:29 wenzeslaus]:
>
> > > More generally, there should probably be separate functions for
"opening" a file or URL in the user's desktop environment.
> >
> > Sorry, I don't get your last point. Would you like to have
`open_something` function in GRASS or do you expect this function to be
available from system or something else?
>
> I think that GRASS should have something. On Windows, this doesn't
require testing for specific programs; subprocess.call(file, shell=True)
should suffice.
>
> > Diverging from the original ticked topic, the
`GRASS_HTML_BROWSER=firefox` blocks the command line even after r56880
when no firefox session is running. However, this is expected and I think
there is no way how to avoid this when we want (probably because of cmd
line web browsers) to use `execlp`.
>
> GRASS_HTML_BROWSER is probably too simplistic. E.g. a GUI browser should
be executed in the background, whereas e.g. lynx shouldn't. But something
like xdg-open should probably be preferred.
As for the ''opening file topic'', we shall create new ticked. However,
for now, I have to say that I don't like the idea of re-implementation of
the `xdg-open`-like functionality in GRASS, especially when primary
backend will be something like `xdg-open` or standard windows
functionality. Although I agree that the current state is insufficient.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2008#comment:34>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list