FvwmMFL: FVWMMFL_SOCKET needs rethinking
Closed this issue · 0 comments
Currently, it's possible to change the listening socket for FvwmMFL
via an environment variable, FVWMMFL_SOCKET
. The reasons for this is that it makes it easier to move the socket path to different locations away from /tmp
, to, say, $FVWM_USERDIR
.
However, this single environment variable is reused across different running fvwm instances which means commands sent via FvwmPrompt or FvwmCommand end up going to the wrong fvwm instance, as it's a case of whichever process reads that first, is sent to the DISPLAY that fvwm is running on.
I think therefore, we should deprecate FVWMMFL_SOCKET
, and replace it with FVWMMFL_SOCKET_PATH
which defaults toTMPDIR
(or /tmp
if not set). Hence:
FVWMMFL_SOCKET_PATH/fvwmmfl_:2.sock
There is no requirement for the name of the socket to ever change, as it's namespaced to the DISPLAY it's running on, and there can only ever be one instance of that running per DISPLAY anyway.
It could be argued why even give the option of changing this if this FVWMMFL_SOCKET_PATH
defaults to $TMPDIR
... it's a valid point, but there could be a few reasons -- if one's $FVWM_USERDIR
were on a NFS filesystem, there can be locking issues with sockets created on them, so having that elsewhere, on a non-NFS FS could make sense. Arguably, this uncommon though.
Given FVWMMFL_SOCKET
is currently used internally by fvwm, and by NsCDE, I consider this change to be low impact, but still a breaking change.