I run an xpra server on one Linux server, and connect to it from another Linux server with 'xpra attach ssh:hostname:100'. On both machines the default login shell is not /bin/sh. It worked fine up to xpra 0.14.12, but after upgrading to 0.14.18 I get "Syntax Error in line 1 near 2" because the command sent with ssh is not a single executable, but a complex command using /bin/sh syntax. I understand this is likely a rare problem, but from a robust design perspectiv it could be worth considering anyway.
Which shell are you using?
For more details, see: #597 (and maybe also #666)
I'm using the shell rc (a unix port by Byron Rakitzis of the Plan9 shell).
I don't think that the command line we pass should fail with any shell, I don't see what is so difficult about it, it generally looks something like:
xpra initenv 2>&1 >> /dev/null;.xpra/run-xpra _proxy :22
If your shell cannot run this... I am tempted to close this as wontfix unless you can suggest a better option.
I have looked into this some more. In this case it's the redirect 2>&1 that gives the syntax error. In rc it is written >[2=1]. Any user can freely switch between the shells listed in /etc/shells, so in generel it is not safe to assume any particular shell when remotely executing commands with ssh. For example, csh and tcsh will also not recognize 2>&1. The safe way is to store the commands in a file with a #! on the remote machine, and execute this file with ssh.
Pretty much every shell out there supports 2>&1
, I am very reluctant to make any change to such a critical command for shells that are going to be used by less than 0.1% of users.
Storing the commands in a file is not an option here.
Unless you can suggest a better option, I am likely to close this as wontfix and just add to the FAQ that the login shell needs to support 2>&1
.
BTW, if your xpra version on the server is greater than 0.13.x, you can drop the redirection completely I think, it is only present for compatibility with older servers which do not support "initenv" at all. Eventually we can drop the redirection when we drop compatibility with older servers, but this will take time. Until then, I guess we could do something like:
XPRA_INITENV_COMMAND="xpra initenv" xpra attach ...
And default to what we have now. But you would still need to define this when running, or have a wrapper script.
I concur that this problem only affects a small number of people, and that a fix should therefore be unobtrusive, or else it will not be worth implementing. If a future version of xpra will not depend on the user's choise of login shell, that will be great, but for now there are probably more important things to fix.
In looking for a workaround I found that I can set up a port forward with ssh and connect xpra through the tunnel using tcp:
ssh -L localhost:3001:localhost:3002 -f example.com sleep 10 xpra attach tcp:localhost:3001
r8682 allows you to do this:
XPRA_INITENV_COMMAND="xpra initenv" xpra attach ssh:HOST:DISPLAY
If you cannot install from source, I'll make a new beta build soon.
Not heard back but I believe what we have is now good enough.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/810