xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 5 years ago

#810 closed defect (worksforme)

xpra attach with ssh doesn't work if login shell is not /bin/sh-compliant

Reported by: Tommy Owned by: Tommy
Priority: minor Milestone: 0.14
Component: client Version: 0.14.x
Keywords: Cc:

Description

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.

Change History (9)

comment:1 Changed 6 years ago by Antoine Martin

Milestone: 0.14

Which shell are you using?

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

comment:2 Changed 5 years ago by Tommy

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

comment:3 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to Tommy

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.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by Antoine Martin

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.