[GRASS-dev] another not quiet GRASS command

[Michael Barton]

Thanks for the clarification. Hopefully NOW I understand how this is
SUPPOSED to work. It will be particularly helpful with wxPython. At least
now I know to check for an incorrect exit code if gcmd.Command doesn't work
as expected. It is also not producing useful error messages. Perhaps it is
not parsing stderror correctly.

Michael


On 9/4/07 3:48 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> So what is *supposed* to happen in a scripting environment is...
>> 
>> 1) non-zero exit code returned
>> 2) show whatever is in stderr to the user
>> 
>> OR
>> 
>> 1) 0 exit code returned
>> 2) do not report with whatever is in stderr (not because it is unimportant,
>> but because it is not an error)
>> 
>> Correct?
> 
> A GUI for GRASS should generally show everything written to both
> stderr and stdout (unless explicitly redirected) to the user,
> regardless of whether or not the command succeeds. IOW, you need a log
> window.
> 
> If a command succeeds but generates warnings, the user should be aware
> of those warnings. It's not uncommon for a command to be able to
> produce results yet have doubts as to whether the result is what the
> user actually wanted.
> 
> In the case of of a non-zero exit code, the output from stderr is
> likely to be useful as part of any error message. If you're going to
> display an error in a message box, the stderr output may be useful.
> 
>> If so, then there may be a bug somewhere in cmd.Comand since it is showing
>> non-meaningful error messages sometimes when the command operates fine.
> 
> It isn't beyond the bounds of possibility that some commands return
> incorrect exit codes.
> 
> In particular, if a script completes by reaching EOF (rather than
> using "exit"), its exit code will be that of the last command, which
> doesn't necessarily reflect the success or failure of the script as a
> whole.
> 
> [Also, some commands have a notion of failure which isn't limited to
> errors. E.g. "grep" fails if nothing matches; 0 => match(es) found,
> 1 => no matches found, 2 => actual error (file not found, etc).]
> 
>> An aside: g.mapset treats as an error (It says "ERROR", so I assume that it
>> generates a non-zero exit code) a situation where the location and mapset
>> are the current location and mapset. IMHO, this should not be an error.
> 
> Agreed.
> 
>> I guess it could be a "warning", but the module is operating correctly in
>> that
>> it is 'changing' to the location and mapset specified; these just happen to
>> be the current one.
> 
> This is similar to the discussions over whether g.remove "fails" if
> the entity (map etc) doesn't exist. For comparison, "rm" fails if the
> specified file doesn't exist whereas "rm -f" doesn't (it fails if the
> file exists but cannot be removed, e.g. due to permissions).

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton