OSGeo
[Bug] Parser rejects empty g.message messages
Hi,
The parser is rejecting empty strings as inputs when sometimes that is wanted.
e.g., using g.message like "echo" by itself to print an empty line:
g.message "" works
but
g.message message="" fails
with:
ERROR: Required parameter <message> not set:
(Text of the message to be printed)
This becomes a problem when grass.message() is used from within a Python script, as message= is always used there. I could add a \n to the start of the following grass.message() call but does that cause trouble if the platform is MS Windows?
Another work-around is to pass an empty space like message=" " but it feels bad.
r.support history="" to insert a blank line in the hist file isn't rejected, but it doesn't insert anything. Both that and g.message work in GRASS 6 if you want empty lines.
thanks, Hamish
The behavior was changed in #958. The motivation was a strange behavior in combination with default values identified in one of r.geomorphon PRs.
Doing g.message message="" to print an empty line is probably not a best practice anyway similarly to message=" ". It has a high runtime cost (subprocess call) and it is less readable than "\n" as part of the message. If \n does not work on Windows, then maybe we should fix that.
I would have to see the actual code in question, but from what I have seen in the past, I would say that 1) \n should be part of the message, 2) not used at all, or 3) the output should be formatted text on standard output (e.g. print in Python) rather than a string of messages (message as in g.message). What do you think about options 2 and 3?
The r.support case is little more difficult for to judge because it is not clear to me what are the different use cases for new line or empty line in the history record. However, my guess would be that my comments on g.message apply here as well.
Using r.support units="" or vdatum="" to clear a previously set metadata value would seem to be a valid use case. (and trying that in modern GRASS versions quietly fails as a noop, with exit code 0, which is not great)
Having a way to add an empty line in to a raster's hist file would also be nice. Maybe the r.support C code there could look for \n in the history= option and take care of it. That could be good for history='Line1 abc\nLine2 abc' functionality too if anyone wanted that. Personally I'd call r.support twice for two lines of text as I care more about readable code than I do about speed in the case of writing out metadata.
FWIW I believe grass.message() translates the \n into a newline in the Python, and the g.message C module simply treats it as two regular characters.
I know grass.message("") is a lot of process overhead to do very little, but I only ever used it a few times in a script to make the module output messages more readable. For me there was always another message on the next line of code. I think my idea was not to have '\n' in the i18n string to be translated. But this way would work for me:
grass.message("\n" + _("Some message to be translated here."))
So I can use that in the case of grass.message().
regards
Can you create a new issue for the r.support case? There is potentially more solutions to that problem than just adjusting the general parser behavior with empty parameters.