Xpra: Ticket #810: xpra attach with ssh doesn't work if login shell is not /bin/sh-compliant

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.



Sun, 15 Feb 2015 04:19:45 GMT - Antoine Martin: milestone set

Which shell are you using?

For more details, see: #597 (and maybe also #666)


Sun, 15 Feb 2015 19:41:04 GMT - Tommy:

I'm using the shell rc (a unix port by Byron Rakitzis of the Plan9 shell).


Mon, 16 Feb 2015 04:46:32 GMT - Antoine Martin: owner changed

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.


Mon, 16 Feb 2015 09:49:19 GMT - Tommy:

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.


Mon, 16 Feb 2015 11:00:22 GMT - Antoine Martin:

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.


Mon, 16 Feb 2015 12:04:23 GMT - Antoine Martin:

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.


Mon, 16 Feb 2015 14:55:31 GMT - Tommy:

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

Wed, 18 Feb 2015 10:09:46 GMT - Antoine Martin:

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.


Sat, 21 Mar 2015 17:53:04 GMT - Antoine Martin: status changed; resolution set

Not heard back but I believe what we have is now good enough.


Sat, 23 Jan 2021 05:06:42 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/810