[GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules

[GRASS GIS]

#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):

 Replying to [comment:28 glynn]:
 > Replying to [comment:24 wenzeslaus]:
 >
 > > I was about to commit the special case for the `explorer` cmd on MS
 Win. However, there is also a special case for `xdg-open`, I'm not sure
 why.
 >
 > I think that the "browser != 'xdg-open'" check is just because xdg-open
 returns a non-zero exit code when run without arguments.
 >
 > > Moreover, I tested also other command and e.g. `firefox` blocks the
 g.manual (it also blocks the cmd line when launched without &).
 >
 > I don't think that find_program() is appropriate for GUI applications.
 E.g. on Windows, many of them will spawn a GUI regardless of any arguments
 given.
 >
 Yes, this would lead to conservative `shutil.which` which just looks.

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

 Anyway, in r56880 I have deleted the test in g.manual since I don't see
 any reason for it. The `execlp` function tests it sufficiently without
 consequences and moreover it is Pythonic EAFP.

 Considering r56880, we don't need the `shutil.which` now, but we may add
 it for/in the future.

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

 == Ticked summary ==

 In r56880, g.manual is not using find_program or any other test function.

 Some special apps (especially those with GUI) may require `shutil.which`
 to avoid strange situations.

 It could be convenient (for both the interface and implementation) to have
 special function to test presents of GRASS modules.

 The interface to of `find_program` was changed to be less error-prone in
 r56867 (and r56869).

 ...other things were invalid, if not or if I miss something please add.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2008#comment:29>
GRASS GIS <http://grass.osgeo.org>