B: Don't munge $DISPLAY in sam's fifo path #729
Conversation
|
It is not clear to me why the :0 vs :0.0 change was required previously in commit 669250d ("Various fixes."). Is this still necessary? We could have B look for both :0 and :0.0 if there are some systems / configurations where this is needed.. |
B first attempts to communicate with sam over its named pipe before
falling back to the plumber if that named pipe cannot be found. sam's
named pipe is placed at a known location which is where B attempts to
find it.
This location is defined in src/cmd/samterm/plan9.c:extstart():
user = getenv("USER");
if(user == nil)
return;
disp = getenv("DISPLAY");
if(disp){
exname = smprint("/tmp/.sam.%s.%s", user, disp);
free(disp);
}
else
exname = smprint("/tmp/.sam.%s", user);
Observe that the path is determined by $USER and $DISPLAY.
However, when B is constructing the path of sam's fifo, if it finds
$DISPLAY is ":0", it overrides $DISPLAY to be ":0.0".
This means that B uses a different path for the fifo then the location
where it was actually created by sam. As a result B cannot find sam's
fifo and B falls back to using the plumber for communication. This is an
issue if the plumber has not been started:
plumb: can't open plumb file: dial unix!/tmp/ns.jpn.:0/plumb: connect /tmp/ns.jpn.:0/plumb: No such file or directory
Note that previously B did not perform this munging - it was added in
commit 669250d ("Various fixes.") with the description:
"B - fixed usage, DISPLAY :0 vs :0.0"
This does not work in the general case so return to using $DISPLAY directly.
Tested on Debian 12 using KDE w/ x11: B is able to communicate with sam
even if the plumber is not running.
Signed-off-by: Jordan Niethe <[email protected]>
|
Re: whether it is necessary: I don't know. @rsc, thoughts? I'm tempted to merge this, as the analysis and reasoning are sound and it clearly fixes a bug, but I also want to know about Mr. Chestson's Fence beforehand. One wonders whether, presuming the DISPLAY must be munged, if it should be done before constructing that path. |
|
I agree with not merging this until the original need for the DISPLAY sam has used the same naming schema for its named pipe since commit So it would seem like B and sam must have both observed a different value for I'm curious how this can happen - plugging / unplugging an external monitor maybe? |
2 participants
B first attempts to communicate with sam over its named pipe before falling back to the plumber if that named pipe cannot be found. sam's named pipe is placed at a known location which is where B attempts to find it.
This location is defined in src/cmd/samterm/plan9.c:extstart():
Observe that the path is determined by $USER and $DISPLAY.
However, when B is constructing the path of sam's fifo, if it finds $DISPLAY is ":0", it overrides $DISPLAY to be ":0.0".
This means that B uses a different path for the fifo then the location where it was actually created by sam. As a result B cannot find sam's fifo and B falls back to using the plumber for communication. This is an issue if the plumber has not been started:
Note that previously B did not perform this munging - it was added in commit 669250d ("Various fixes.") with the description:
This does not work in the general case so return to using $DISPLAY directly.
Tested on Debian 12 using KDE w/ x11: B is able to communicate with sam even if the plumber is not running.
Signed-off-by: Jordan Niethe [email protected]
It is not clear to me why the :0 vs :0.0 change was required previously. Is this still necessary? We could have B look for both :0 and :0.0 if there are some systems / configurations where this is needed..