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

GRASS GIS trac at osgeo.org
Sat Jun 22 08:20:18 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 glynn):

 Replying to [comment:24 wenzeslaus]:
 > I've committed the small fix for r56867 in r56869 (Python says ''can
 only concatenate list (not "tuple") to list'').

 Er, right.

 > There is except without OSError, mentioned before, is there any reason
 for this?

 Nothing particular. It's mainly a case of determining "works" versus
 "doesn't work" without caring about the reasons for the latter. If other
 errors are possible, should the caller be concerned with them? I.e. should
 we just allow exceptions other than `OSError` to propagate up to the
 caller? In any case, it should probably be restricted at least to either
 `StandardError` or `Exception`, so that it doesn't catch

 > 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

 More generally, there should probably be separate functions for "opening"
 a file or URL in the user's desktop environment.

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

More information about the grass-dev mailing list