Xpra incorrectly escapes characters in run-xpra wrapperscript, causing remote sessions to fail to find server sockets

[firazy]

Installed Xpra 0.17.5 on Fedora 23 via dnf, and 0.17.5-r13487 on Windows 10 to use as client.

After many failed attempts at attaching, xpra never finding the display, i wrapped ~/.xpra/run-xpra on server with a strace call.

Result:

stat("/home/user.name\\@domain.net/.xpra", 0x<pointer>) = -1 ENOENT (No such file or directory)

The problem doesn't appear when running xpra locally. I'm no expert regarding xpra internals, but my take on it is that xpra in client mode tries to apply local (Windows') naming conventions and escapes the at sign, despite it being valid for the server. This results in searching for an non-existant path and failing.

A workaround is to use a global sockets-dir with a simple name (/var/run) or for lazy people like me, to symlink the incorrect homedir to the correct one...
Once this is done, Xpra works as intended.

I'm thinking this defect should either be fixed, or at least documented somewhere for people that run into this problem in the future. Sadly i'm no Win32 nor xpra expert, so providing a proper patch might be beyond my capabilities.

[Antoine Martin]

The next version will also use /var/run aka XDG_RUNTIME_DIR, see #1291

We should still try to fix your problem. I'm not sure which side is doing this escaping.
Do you have the full strace? I would like to see what command line arguments are used to execute xpra so I can try to fix this without needing to use a Windows system if possible.
Can you please also post:

xpra_cmd showconfig

[firazy]

Actually after looking a bit more thoroughly into the strace, it turns out the problem is not Windows Related indeed, and my guess was incorrect... The at-sign is already escaped wrongly in ~/.xpra/run-xpra that is generated on server-side.

Here are some excerpts from the generated run-xpra wrapper:

...
HOME="/home/user.name\@domain.net"; export HOME
...
PWD="/home/user.name\@domain.net/.xpra"; export PWD
...
cd "/home/user.name\@domain.net/.xpra"

This causes the cd to fail, but since xpra is later launched with an absolute path, it proceeds anyway.
As such, even locally, running xpra with "xpra list" works, while running "~/.xpra/run-xpra list" fails.

[Antoine Martin]

backport of the new shell-quote function

[Antoine Martin]

Does the patch above fix things?

If that doesn't fix it (it should), please post:

python -c 'import os;print(os.environ["HOME"])'

[firazy]

This fixes it indeed :)
Thanks!

[Antoine Martin]

Applied in r14416, was already tracked in ticket:1259#comment:3.