grass.script: Fallback to print when g.message fails

[wenzeslaus]

A certain situation on Windows described in #5717 produces 'OSError: Cannot find the executable g.message' which is missing the original message. While such message is an indication of a deeper issue, the traceback misses the original message. This fallback approach show the message as the function was asked to do even when the subprocess had issues. It attaches the exception which may be confusing, but also may be quite helpful to understand the overall situation (which may not be related to the message itself).

[wenzeslaus]

@echoix, this reacts to a traceback in your comment in #5717. My understanding you can't test it in the same situation now when #5717 is merged. I tested locally by breaking the g.message call. This resulted in:

grass ~/grassdata/nc_basic_spm_grass7/user1/ --text
Starting GRASS...
Cleaning up temporary files... (Additionally, there was an error: Cannot find the executable g.messagex)
...
GRASS nc_basic_spm_grass7/user1:grass > r.mask -r
No existing mask to remove (no raster named MASK) (Additionally, there was an error: Cannot find the executable g.messagex)

Both your description and the traceback indicate that the message for your now would be with this PR but without #5717 or with g.message broken:

Location <...> already exists. Operation canceled. (Additionally, there was an error: Cannot find the executable g.message)

In a standard case, the message should be:

ERROR: Location <...> already exists. Operation canceled.

[echoix]

I can try to revert locally the previous PR. But you already did it.

Was there some particular way you would want me to try out, and see if it helps or not?

[wenzeslaus]

I don't think that's necessary. On Linux, it works either way, but for testing, I broke the g.message call to get the message.

[wenzeslaus]

I don't fully understand what the second commit message tries to say about the exit codes.

When g.message is asked to print an error message with -e, it returns a non-zero return code.

$ grass --tmp-project XY --exec g.message "Hello"; echo $?
Hello
0
$ grass --tmp-project XY --exec g.message -e "Hello"; echo $?
ERROR: Hello
1

This seems undocumented, but I guess it made sense for shell scripting.

But in either case, I agree that we should be able to show the error message without having to go through our binaries (when we can't find them).

+1

Did you consider or try what the output would look like if exception chaining was used?

The chaining would lead you to the g.message not found error, but the actual error is whatever is being printed.

With this, we are kind of hiding the fact that there's an error.

I do print the "additional" error, so that's how I'm trying to counter that.

The g.message must do something more than printing, otherwise we would simply be using prints. So not being able to make use of g.message is still a problem

It evaluates the verbosity level.

Thanks for the review. I'm merging this.

[echoix]

Fine with me with the questions answered