[GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
----------------------------------------+-----------------------------------
 Reporter:  pvanbosgeo                  |       Owner:  grass-dev@…              
     Type:  defect                      |      Status:  new                      
 Priority:  normal                      |   Milestone:  7.0.0                    
Component:  Default                     |     Version:  svn-trunk                
 Keywords:  g.region, r.colors, r.mask  |    Platform:  Linux                    
      Cpu:  x86-64                      |  
----------------------------------------+-----------------------------------

Comment(by glynn):

 Replying to [comment:20 cmbarton]:

 > It is not critical but I'm not sure I'd call it an enhancement. Not
 really a bug either, though it will appear to be one to many users. The
 important conceptual issue is, should the default behavior of GRASS
 modules when called without arguments be
 >
 > 1. to launch a GUI dialog?
 > 2. to do something?

 Arguments or not, the '''default''' behaviour behaviour should be to do
 something. We're discussing the behaviour in the event of an error, i.e.
 if the supplied arguments are insufficient for the module to actually do
 something.

 In that situation, my preference would be an error message, preferably a
 more useful one than
 {{{
 Unable to access the X Display, is $DISPLAY set properly?
 }}}
 If I wanted GUI dialogs, I'd use the GUI.

 > My vote for #1 comes from thinking about usability for people who are
 novice or infrequent users of the command line
 Optimising the command-line interface for people who don't use it at the
 expense of those who do doesn't seem particularly sensible. Also,
 optimising for novice users results in something which is useful for the
 first few weeks then a nuisance for the next decade, which again seems
 like a poor trade-off.

 > I think the argument for #2 is primarily one of easier, more rapid use
 of modules from the command line by experienced and frequent users. There
 may be other arguments that have not been articulated yet.
 There's also the fact that it can result in command-line modules blocking
 forever in the case that the connection to the X server succeeds but
 there's no user to interact with it. I.e. the same problem as with the
 previous terminal-based prompting, except that closing stdin won't save
 you (unsetting DISPLAY will, at least on Unix, provided that you've
 already anticipated that failure mode).

 To that end, I'd rather GUI dialogs were never displayed, so that e.g. a
 shell script which does "r.module $args" (when $args is empty for whatever
 reason) sees an error rather than a module which just runs forever. That
 would also be consistent with almost every other command-line utility from
 every package which isn't GRASS.

 The problem is that it's rather hard for a module to determine whether
 interactivity is a plus or a minus. An environment variable wouldn't
 necessarily help; if it's set for an interactive shell, any scripts run
 from the shell would inherit it. They'll also inherit the fact that stdin
 is a tty and $DISPLAY is set.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1778#comment:22>
GRASS GIS <http://grass.osgeo.org>