-
-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xpra ssh reconnect: argument quoting on windows #4355
Comments
Is this running from some weird shell? mingw perhaps? |
The original However, when reconnecting, xpra does some commandline re-arrangements, I guess that this will be the correct place where reconnect is handled: Line 1504 in 4ead552
For some strange reason I don't see the
|
It does, but like I said, it works fine for me from |
So did I.
Ah! I think I looked at the wrong place. Line 2456 in 4ead552
Unfortunately there are no debug logging statements here. Could you add some that document Btw.: I don't know if this is still relevant but there has been a suggestion to use the https://bugs.python.org/issue19124#msg198599 |
Could the problem come from here (see #4026): Lines 2337 to 2344 in 4ead552
Somehow it is getting confused? (works for me from a python shell)
I am a little bit wary of adding logging statements there, so added carefully in 5852c2a, try 6.2-r36679 or later.
These constraints are fine for us. We definitely don't want the old process lingering around, so terminating it as soon as the new process starts is fine. |
I don't think so. The error output shows that the
Thanks! Hopefully this will provide further insights.. |
OK. Both
So the problem could be inside microsofts windows c runtime version of execv? Microsoft documentation states that spaces are not supported:
Maybe that's why
|
Based on this, I have added bdbf53f (v6.2-r36680 or later) |
Thanks. But this won't work because it only quotes the program path, not the arguments. This illustrates the problem:
I didn't manage to get this working using However, we shouldn't use Unfortunately windows simply doesn't provide a way to replace the running process like
In both variants |
so 'xpra start' and 'xpra attach' can re-use more code
Well, that's a pain. |
Yay!!! 🥳 |
On windows, xpra seems to incorrectly parse the command and its arguments when reconnecting after the ssh connection has been lost.
This connection works fine but xpra crashes when reconnecting after the ssh connection had been lost:
I could avoid calling Xpra_cmd with the full path of course, but for enabling ssh agent forwarding, I am using:
... which also leads to the same problem when parsing
--ssh="plink -A"
:The text was updated successfully, but these errors were encountered: