I have finally had the time to take a little better look at the code and actually test ximgview/wxpyimgview. I replaced my first PR [1] for deleting GRASS_NOTIFY with a PR [2] with which a G_warning is issued if the system call fails.
The documentation on using ximgview/wxpyimgview, including the signal handling, could probably be improved. I will at least file a ticket with that aim. Thank you Glynn for jumping in on this, I very much appreciate it! [1] https://github.com/OSGeo/grass/pull/2135 [2] https://github.com/OSGeo/grass/pull/2705 > On 4 Mar 2022, at 20:28, Glynn Clements <gl...@gclements.plus.com> wrote: > > > Nicklas Larsson via grass-dev wrote: > >> I personally never had the need for the use of GRASS in this way, so forgive >> my ignorance in this regard. >> However, one thing stands out very clear from my newly gained experience: >> there is a lack of documentation on this use of GRASS_NOTIFY. For instance, >> it is not clear to me is whether it is required or optional to set >> GRASS_NOTIFY >> with e.g.: >> >> export "GRASS_NOTIFY=kill -USR1 `pidof ximgview`” >> >> for this to work as intended. Surely it is not expected a user should look >> for this >> information in the mailing list. > > I think that it's "expected" that the user will just use the GUI. > > It seems doubtful that anyone (other than me) actually used this. I no > longer actively follow GRASS; I only remained subscribed to the list > for cases (like this) where someone is asking about arcane details of > stuff I worked on in the past. > >>> What sort of "sanitisation" would you suggest? The variable is set by >>> the user, its value is passed directly to the shell. >>> >> I’d say it would be better to avoid sanitation, with what I mean making sure >> GRASS_NOTIFY hasn’t been compromised, at all. Couldn’t the desired outcome >> of using GRASS_NOTIFY be implemented in another way? > > Well, it could be made a GRASS ($GISRC) variable. A fixed command name > could be inconvenient if you have multiple GRASS sessions in different > shells (again, I don't think this is "typical" user behaviour). It > could use some other mechanism entirely (e.g. a filename identifying a > socket or named pipe to which D_close_driver would write) would work, > but would be a non-trivial effort for something that probably isn't > even used. > > I'm not sure manipulating GRASS_NOTIFY gets you much compared to > manipulating e.g. EDITOR or BROWSER. And unless there's been a > significant effort on security since I was active, using GRASS with > untrusted inputs or an untrusted environment has much bigger issues. > > In any case, ximgview/wxpyimgview don't appear to have had any > substantial changes or issues (i.e. nothing that doesn't appear to be > a repository-wide clean-up) in the last decade, so non-GUI usage of > the display subsystem is probably a non-issue at this point. > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev