[GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting

[GRASS GIS]

#2326: Command functions in grass.script.core miss a correct error reporting
-------------------------+--------------------------------------------------
 Reporter:  wenzeslaus   |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  major        |   Milestone:  7.1.0                    
Component:  Python       |     Version:  svn-trunk                
 Keywords:  script       |    Platform:  All                      
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
Changes (by wenzeslaus):

  * priority:  normal => major


Comment:

 Here is the usage of `*_command` functions from `grass.script.core` and
 how their output is checked. The statistics is alarming, so raising
 priority.

 || function || checks rc || does not check ||
 || `run_command` || 109+33 || 285+501 ||
 || `write_command` || 7+2 || 17+33 ||

 Both `run_command` (just runs the command synchronously) and
 `write_command` (puts string to stdin) returns a subprocess return code
 but most of the code does not check it (0.7 in trunk and 0.9 in addons).
 We must expect that user scripts might be same or worse than addons.

 || function || usages ||
 || `start_command` || 4+2 ||
 || `pipe_command` || 24+1 ||
 || `feed_command` || 18+1 ||
 || `read_command` || 119+76 ||
 || `parse_command` || 66+9 ||

 For `start_command`, `pipe_command` and `feed_command` it is hard to tell
 if the return code is checked without really looking to the source code.

 In case of `read_command` (returns stdout as string) and `parse_command`
 (applies function to `read_command` result) we know that the return code
 is not checked since the function should do this and it does not. In case
 of `parse_command` the error might be at least generated during the
 parsing. In case of `read_command`, the standard output might checked too.
 In case the checking accepts things like empty sting or `None` or no error
 is generated during parsing, it is completely the same as with
 `run_command`.

 Note that results are approximate, e.g., `(grass\.)?` might not be
 completely correct. Used grep commands:

 {{{
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE
 '(grass\.)?run_command' . | grep -E "(if | = ).*run_command"
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE
 '^\s*(grass\.)?run_command' .
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE 'pipe_command' .
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE 'feed_command' .
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE 'read_command' .
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE 'parse_command' .
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE 'write_command' . |
 grep -v "test_rcategory_doctest" | grep -E '(if | = ).*write_command'
 grep --exclude="*svn*" --exclude-dir="*dist.*" -IrnE 'write_command' . |
 grep -v "test_rcategory_doctest" | grep -vE '(if | = ).*write_command'
 }}}

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