FvwmMFL: FVWMMFL_SOCKET needs rethinking

[ThomasAdam]

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.