It is there as one of the many attempts to improve the rendering workflow. It is not documented and not used in the code and there is no motivation in the commit message.

However, I double checked and some or all (?) usage of ximgview and wxpyimgview can be broken if removed. See:

A suitable (although rather primitive) viewer is available as visualisation/ximgview. This will refresh its display from the file either at regular intervals, or when it receives SIGUSR1. If the environment variable GRASS_NOTIFY exists, its value will be executed via system() whenever a d.* command completes, so you can use e.g.:

export "GRASS_NOTIFY=kill -USR1 `pidof ximgview`"

[GRASS-dev] Shell scripts, Glynn Clements, Dec 2009 (https://narkive.com/9nUlmRam.12)

SIGUSR1 is used in ximgview and wxpyimgview. wxpyimgview could probably use watchdog as wxGUI is using but it may not be the same.

I did see that single mention in ML, but that’s all. I’m still convinced this is a hack/debug/test thing. Besides, it is not particularly safe to pass an env var unchecked to a system call.

I'm for removing it, but doesn't that mean we need to remove SIGUSR1 from in ximgview and wxpyimgview, too? Then the question is how they will update? Both ximgview and wxpyimgview stand somewhat outside of the standard system as alternatives when the main GUI or d.mon wx* does not suite your needs. It is little hard to make decisions about these. I think it is fair to say that they are ad hoc additions. This might be something to discuss on grass-dev.

This might be something to discuss on grass-dev.

I agree, just initiated.

Closes this in favour of #2705.