grass.script: Fallback to print when g.message fails#5849
grass.script: Fallback to print when g.message fails#5849wenzeslaus merged 2 commits intoOSGeo:mainfrom
Conversation
A certain situation on Windows described in OSGeo#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).
|
@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: 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: In a standard case, the message should be: |
… results in a non-zero return code (likely to facilitate shell scripting).
|
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? |
|
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. |
echoix
left a comment
echoix
left a comment
There was a problem hiding this comment.
I don't fully understand what the second commit message tries to say about the exit codes. 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).
Did you consider or try what the output would look like if exception chaining was used?
With this, we are kind of hiding the fact that there's an error. 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
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
1This seems undocumented, but I guess it made sense for shell scripting.
+1
The chaining would lead you to the g.message not found error, but the actual error is whatever is being printed.
I do print the "additional" error, so that's how I'm trying to counter that.
It evaluates the verbosity level. Thanks for the review. I'm merging this. |
|
Fine with me with the questions answered |
2 participants
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).