FvwmCommand doesn't find socket #1034
Comments
akovalenko
added a commit
to akovalenko/fvwm3
that referenced
this issue
Jun 10, 2024
Follow-up to da4387b FvwmMFL: introduce FVWMML_SOCKET_PATH for namespacing. It breaks FvwmCommand for me because instead of taking FVWMMFL_SOCKET from the environment, FvwmCommand guesses it from FVWMMFL_SOCKET_PATH (incorrectly, DISPLAY=:1.0 while socket being :1.sock) When running FvwmCommand from a specific fvwm instance, FVWMMFL_SOCKET is available, so let FvwmCommand use it. In the "outer" environment where only FVWMML_SOCKET_PATH is available, let it resort to guessing socket by $DISPLAY. Fixes fvwmorg#1034.
|
Hi @akovalenko Thanks. Can you please try This should now be working correctly. |
|
Hi @ThomasAdam, |
|
Hey @akovalenko Awesome. Thanks for testing! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After commit da4387b, I started using FVWMMFL_SOCKET_PATH to put sockets into $XDG_RUNTIME_DIR/fvwm (which is the right place for multi-user system)
FvwmMFL (from the default config) creates a socket and provides FVWMMFL_SOCKET in the environment.
The problem is, FvwmCommand in da4387b doesn't take FVWMMFL_SOCKET into account, resorting to guessing the socket path from FVWMMFL_SOCKET_PATH and DISPLAY. On my system it happens to guess wrongly: when the socket is created, it uses DISPLAY=:1 (as received from .Xsession), but under fvwm3, I have DISPLAY=:1.0 (with screen number).
Upfront Information
Fvwm3 version (run:
fvwm3 --version): fvwm3 1.1.1 (1.1.0-64-gf0366381)with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS
Linux distribution or BSD name/version: Ubuntu jammy
Platform (run:
uname -sp): Linux x86_64Expected Behaviour
Launched XTerm from FVWM, started FvwmCommand Module FvwmConsole, expected to see the console
Actual Behaviour
Steps to Reproduce
How can the problem be reproduced?
The text was updated successfully, but these errors were encountered: