[GRASS-dev] another not quiet GRASS command

[Glynn Clements]

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

-- 
Glynn Clements <glynn at gclements.plus.com>