On 05.05.2015 12:48 AM, nanook@eskimo.com wrote:
That's unfortunate, however it works fine with ksh, and remmina whichuses nx works fine with csh however it's not available for Apple, so it looks like Apple users are just pretty much screwed. Not the response I was hoping for but if that's what it is, that's what it is.
Well, there isn't a real technical reason why we support bash only, it's just that the current code kind of relies on it to work and has never been testing with anything else but the bash-like dash and maybe the POSIX-compatible dash/bash sh-emulation.
ksh is bash-like enough to by chance "just work".
You'll see weird behavior with csh and others, though.
Besides making all remote calls POSIX sh-compatible, I wouldn't know how to fix the problem. And I'm not even sure csh and friends *are* POSIX sh-compatible, without looking it up first...
That wasn't meant as a "bash or die" statement, but given the current state of affairs, it comes close to that.
Mihai
What seems odd to me is that if I originate from a Ubuntu machine, withcsh as the shell on the target host, it works. It only breaks if originated from a Mac. It would seem there should be some way to separate the shell x2go uses to process commands, i.e., explicitly invoking /bin/bash instead of just assuming it's what will process the commands, for instances where users are using something else. Ksh is a superset of bourne shell as is bash so that's probably why it has enough in common to work.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Tue, 5 May 2015, Mihai Moldovan wrote:
Date: Tue, 05 May 2015 00:55:54 +0200 From: Mihai Moldovan <ionic@ionic.de> To: nanook@eskimo.com Cc: "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: Re: [X2Go-User] Keyboard Translation Mac/OS
On 05.05.2015 12:48 AM, nanook@eskimo.com wrote:
That's unfortunate, however it works fine with ksh, and remmina whichuses nx works fine with csh however it's not available for Apple, so it looks like Apple users are just pretty much screwed. Not the response I was hoping for but if that's what it is, that's what it is.
Well, there isn't a real technical reason why we support bash only, it's just that the current code kind of relies on it to work and has never been testing with anything else but the bash-like dash and maybe the POSIX-compatible dash/bash sh-emulation.
ksh is bash-like enough to by chance "just work".
You'll see weird behavior with csh and others, though.
Besides making all remote calls POSIX sh-compatible, I wouldn't know how to fix the problem. And I'm not even sure csh and friends *are* POSIX sh-compatible, without looking it up first...
That wasn't meant as a "bash or die" statement, but given the current state of affairs, it comes close to that.
Mihai
On 05.05.2015 02:57 AM, Robert Dinse wrote:
What seems odd to me is that if I originate from a Ubuntu machine, withcsh as the shell on the target host, it works. It only breaks if originated from a Mac.
That's because the command chain is only executed by the OS X version of X2Go Client. Sorry if I was unspecific about that. xmodmap is *not* executed on Linux or Windows, so the "problematic" command is never run through X2Go Client on these platforms.
The whole call is doomed anyway, because it's doing something like # echo "HUGE LIST OF XMODMAP OUTPUT FROM THE OS X CLIENT MACHINE" | xmodmap -
Now of that huge list by chance includes a quote character, the fun begins.
It would seem there should be some way to separate the shell x2go uses to process commands, i.e., explicitly invoking /bin/bash instead of just assuming it's what will process the commands, for instances where users are using something else.
That's one solution, yep. Not sure why the code is currently not doing that, though. It would add another dependency on bash, but would make things (not only for that problem, but in general!) *a lot* more deterministic. Thanks.
Ksh is a superset of bourne shell as is bash so that's probably why it has enough in common to work.
Exactly.
Mihai
For what it's worth it might be better to make it dependent upon/bin/sh rather than bash. It must only need those facilities since it works with different supersets of /bin/sh, and /bin/sh is ubiquitous, where as bash may not be present on some more anitique Unixes (though it will compile on anything, I've even got it compiled on an antique Sun SS-10 running SunOS 4.1.4)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Tue, 5 May 2015, Mihai Moldovan wrote:
Date: Tue, 05 May 2015 03:02:28 +0200 From: Mihai Moldovan <ionic@ionic.de> To: Robert Dinse <nanook@eskimo.com> Cc: "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: Re: [X2Go-User] Keyboard Translation Mac/OS
On 05.05.2015 02:57 AM, Robert Dinse wrote:
What seems odd to me is that if I originate from a Ubuntu machine, withcsh as the shell on the target host, it works. It only breaks if originated from a Mac.
That's because the command chain is only executed by the OS X version of X2Go Client. Sorry if I was unspecific about that. xmodmap is *not* executed on Linux or Windows, so the "problematic" command is never run through X2Go Client on these platforms.
The whole call is doomed anyway, because it's doing something like # echo "HUGE LIST OF XMODMAP OUTPUT FROM THE OS X CLIENT MACHINE" | xmodmap -
Now of that huge list by chance includes a quote character, the fun begins.
It would seem there should be some way to separate the shell x2go uses to process commands, i.e., explicitly invoking /bin/bash instead of just assuming it's what will process the commands, for instances where users are using something else.
That's one solution, yep. Not sure why the code is currently not doing that, though. It would add another dependency on bash, but would make things (not only for that problem, but in general!) *a lot* more deterministic. Thanks.
Ksh is a superset of bourne shell as is bash so that's probably why it has enough in common to work.
Exactly.
Mihai
On 05.05.2015 03:09 AM, Robert Dinse wrote:
For what it's worth it might be better to make it dependent upon/bin/sh rather than bash. It must only need those facilities since it works with different supersets of /bin/sh, and /bin/sh is ubiquitous, where as bash may not be present on some more anitique Unixes (though it will compile on anything, I've even got it compiled on an antique Sun SS-10 running SunOS 4.1.4)
In general, yes, but I honestly don't know if X2Go Client is not by any chance issuing commands non-POSIX-sh-compatible. I'll have to very carefully asses this prior to switching to /bin/sh.
Also, this *will* make quoting more complicated, which is probably the initial reason it wasn't implemented this way.
/bin/sh -c 'commands "here shall NOT use single quotes"; or '"'"else"'"
Mihai
Yes, I understand that. It's more complex on the development side,but from an end users standpoint people want things to "just work", and not have to change their whole way of doing things for one application. It's like the work on supporting compositing desktops, it's going to be a complex nitemare but more and more distributions are going to that so sooner or later it will need to be done or the software will become obsolete.
Looking far into the future, much faster speeds are going to become more widely available, Google is providing gigabit service in some cities, Comcrap, er, Comcast, is rolling out 2 gigabit service in some locations (here they can't even get 20mbit to work reliably), and when that becomes more widely available, people are going to want full 3-d accelerated graphics remotely for everything from 3d modelling applications, 3d medical imaging, virtual reality, gaming.
I'm wondering how to handle it from a server side, a bunch of GPUs tiedtogether, it's going to require some significant computational power.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Tue, 5 May 2015, Mihai Moldovan wrote:
Date: Tue, 05 May 2015 03:28:01 +0200 From: Mihai Moldovan <ionic@ionic.de> To: Robert Dinse <nanook@eskimo.com> Cc: "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: Re: [X2Go-User] Keyboard Translation Mac/OS
On 05.05.2015 03:09 AM, Robert Dinse wrote:
For what it's worth it might be better to make it dependent upon/bin/sh rather than bash. It must only need those facilities since it works with different supersets of /bin/sh, and /bin/sh is ubiquitous, where as bash may not be present on some more anitique Unixes (though it will compile on anything, I've even got it compiled on an antique Sun SS-10 running SunOS 4.1.4)
In general, yes, but I honestly don't know if X2Go Client is not by any chance issuing commands non-POSIX-sh-compatible. I'll have to very carefully asses this prior to switching to /bin/sh.
Also, this *will* make quoting more complicated, which is probably the initial reason it wasn't implemented this way.
/bin/sh -c 'commands "here shall NOT use single quotes"; or '"'"else"'"
Mihai
-
Mihai Moldovan -
Robert Dinse