OH GOD I'M SUCH A NOOB
wait let me explain this.
I am somewhat familiar with linux, and i own a raspberry pi which i use as a ssh server, but i recently got hold on a old Dell Precision M4300 Laptop, so i got a minimal debian installation on that as well.
Howerver, as i logged in directly (as using the display and keyboard on the machine) to the laptop, i discovered a strange thing:
When executing a command resulting in a new menu, for example
nano .bashrc
, and than exiting that menu, the output gets shown where previously only the list of typed in commands and outputs was. This seems somewhat logical, as the "menue" is a "command output" as well, but when sshing to the machine from my windows machine (via gygwin or putty), the "menue" closes and i see the list of prompts and command outputs again, the same happens when sshing to the raspi. Is this a speciality of Putty / Cygwin? Can i make bash on the machine clean up after nano?
Thanks for any replys, i am really out of ideas here, i don't even know the right search term...
The functionality you are talking about is implemented by smcup and rmcup which can be used by editors such as nano and other applications to save and restore the screen when they are invoked and exited. This functionality is known as alternate screen and you can find more documentation regarding it here. Some people actually are quite annoyed by it.
Unfortunately, if you're using the linux virtual console instead of X windows or even connecting into the machine via ssh from another computer, then it seems like this feature is not available, according to this other post.
Related
Background: I look after the Raspberry Pi version of Scratch for the Foundation. Mostly this is a matter of Smalltalk programming, VM developing and some very frustrating moments with shell scripts.
Right now I'm baffled and annoyed by what seems likely to be a unix permissions or related issue when using xrdp to connect to a Pi from any other machine. I know that it's not a problem directly with theSqueak VM since google has revealed quite a few other applications having similar looking issues. Part of my problem is that I don't know enough about this area to really know what to search for to narrow things down.
So, problem description -
The current Scratch system runs on the Squeak Cog VM (see https://github.com/OpenSmalltalk/opensmalltalk-vm), which amongst other things uses pthreads and needs to set the thread priority. That used to be something that required modifying some config but more recent (Raspbian) kernels have no problem with it.
Except when using xrdp, which is a pain because I mostly work with my Pi via xrdp to my iMac. To handle this I have to prepend a 'sudo -E' which is tolerable for a developer but not really good for general users.
I have a similar problem with a trivial file copying command used in the VM make process as well, and that doesn't use any thread stuff nor priority work, but does require me to sudo make in a terminal window.
As an experiment I tried using tightvnc, to see if anything might work better. After reading the full install instructions (https://www.raspberrypi.org/documentation/remote-access/vnc/) and adding the auto-startup init.d script etc, it seemed like maybe we were in luck because the sudo isn't needed! Hooray! Of course, I was a bit disappointed by the seemingly slower display handling, but never mind.
Sadly this isn't even close to the end of the story. I've recently been working on completing the support for the X composition input window system that allows Japanese and other non-Latin1 type language users to enter characters more easily. It's pretty clever, once you've installed iBus, Anthy, many fonts and done some setup. But, while it works perfectly well on a Pi with a direct display, and fine on an xrdp display (with the sudo to allow Scratch to run in the first place, of course) it simply won't work via vnc with or without a sudo.
Googling shows a large number of other applications having problems in odd ways with the relevant XCreateIC() call (see https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm-display-X11/sqUnixX11.c line:1659 for our usage) but nothing I can make much connection to vnc for. To add to the annoyance the combo window appears ok for Terminals!
To summarise-
direct display - no problems for either the pthread priority or the compo window
xrdp - needs sudo for pthreads priority but the compo window works ok
vnc - doesn't need sudo for pthread priority but compo window doesn't work.
What I need: help with finding out what causes these problems and maybe even solutions. A way to configure xrdp to not require 'sudo' would be nice.
To my delight a colleague found what appears to be a very effective answer to this; it seems that the /etc/pam.d/common-session file needs a single line adding.
Edit the file and add
session required pam_limits.so
This allows all the applications I have that previously had permission related problems to run under xrdp. Another Scratch user who had a similar issue using PuTTY reports that it solved that issue as well.
I want to script opening chromium in kiosk mode under Linux (openSUSE 12.3) and XWindows, while controlling which monitor chromium appear in. I also need to have this script be run outside of a standard xterm, e.g. via ssh into the machine where chromium AND the display will run (i.e. I want the application to appear on one of the displays of the machine I'm connecting to, not the machine I'm connecting from).
I can do everything I want by hand in xterm on the target machine, but I won't be running these scripts in xterm. Somehow, the xterm environment is special: it knows how to talk to the containing XWindows session, and in fact knows which actual monitor it is hosted on. For example:
When I ssh into the machine and try to run an XWindows GUI on the target machine's display, it (reasonably) complains "Can't open display". However, even when I set the DISPLAY environment variable to the same value I see in xterm, I still get the error (although it now includes the current DISPLAY value). I've also tried setting DISPLAY to a variety of permutations on ":X.Y", where X and Y are small integers, but again to no avail.
If I run chromium in --kiosk mode from xterm, it takes over the monitor that currently contains the xterm window. If I drag xterm to my other monitor then chromium will launch in that monitor. I want that control when I launch chromium from my script, but can't figure out the background magic.
For window manipulation, I've seen suggestions to use wmctrl or devilspie, but I'm a bit nervous about depending on tools that haven't been updated in years. I'd also prefer to have chromium launch in the right place right off the bat, rather than having it appear in the wrong place and then be moved. And neither app can help me launch the app remotely.
So, here are the questions. First, how does xterm tell chromium how to connect to the right XWindows session and monitor? Second, how do I simulate that from a completely separate ssh connection? (Again: it's more than just the DISPLAY variable.)
Thanks,
Dan
You can't open X client on the target machine's display because of permissions: not anyone that can ssh into a machine may "take ownership" of it's screen. These are things controlled by xset -- read up on it.
As for the display: I assume that the specific monitor is controlled by the second part of the DISPLAY environment. At least that's what I remember from reading about X. I've never actually worked in a multi-monitor X environment.
Xterm is not special. Your mouse pointer is. Chromium will appear on the monitor your mouse pointer happens to be in. This is probably the default behaviour of your window manager.
Chromium does not respect the usual window position requests. You cannot tell Chromium where to appear, you must tell your window manager where to place the Chromium window. Methods of doing that, if they exist, totally depend on what window manager you have.
If you ssh to your machine as the user that has started the X session, you should have no problem connecting to that session.
I'll start off by saying I'm no Linux guru, or even close. I use it to develop embedded applications and it serves my purposes just fine as such.
I have a program which is running (I suppose the correct terminology is "running in a terminal") on a CentOS 6.3 box. For debug and statistics, I have a routine which monitors the keyboard (stdin file) and spits out items as requested by the given key-presses. That all works fine when I'm sitting in front of it.
But I'd like to be able to perform these simple functions: press a key, see some output, remotely. I can SSH into the box and execute commands, but I can't "see" this program.
I have tried searching "communicating with other terminals using ssh" and myriad variations, but I guess I'm not asking this correctly -- the search results are worthless.
What I'd like to be able to do is login to my account and then somehow "see" my program running and type keys and see its output. Is this a stdin/stdout redirection issue?
I apologize in advance if this is painfully obvious and I'm just an idiot, but I'd still like to know how to do it... :)
If you use the linux 'screen' utility, you can re-attach to the original terminal session that you used to start the program. basically you just type screen and then run your program. here is more useful info on screen:
http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to
I currently have a tiny, headless (and I certainly want to keep it that way :) ) Linux Virtual Machine set up with Vagrant and VirtualBox which, for testing, I want to run an X11 application (Firefox) whose output comes to Xming on my real machine. All that's hunky dory, working perfectly, but I'm not happy yet!
What I want to be able to do is do a few setup things, make sure everything's running correctly, then disconnect from the server and let the testing run it's course. If however something goes wrong, or I want to just check the current status of things (some of the tests may run into hours), I'd like to then hop back onto the server and point the X11 output to my machine again. But despite a good deal of Google-ing and learning loads about X11 that I didn't know a few hours ago, I can't find anything about choosing where the output of an X11 application goes, except at startup, ie;
DISPLAY=:10 firefox &
I had read some random blog post that Xephyr XServer did this (kind of act as an intermediate X11 buffer, which then redirects if you want it to, otherwise just outputs to /dev/null), but I can't find any other reference to it, or anything else doing that.
There's a program called Xpra that works sort of like "screen" but for X-sessions. It would start a separate X session from the main one, for the remote access, but you can connect/disconnect to it at will from the host machine.
http://www.xpra.org/
I currently have one acceptable way to do this, which will serve my purpose, I have a vnc4server running that takes firefox's output, and then I can connect and disconnect to that without any issue at all, just like a normal VNC server. This allows me to do what I want to do, but not how I want to do it. I'd like to be able to do this without the need of a VNC server at all.
I do this all the time using VNC and it is very easy, but I am curious about a few things like XDMCP. As I understand it, this is a way of creating the entire desktop on a remote X-Server which seems fairly elegant.
Several years ago, I worked on a Solaris server and multiple developers had X-Servers running in Windows and we were able to access a full remote X-desktop. All my efforts so far in X based systems seem to indicate that only one instance, remote or local, of the desktop can be loaded, so I guess this Solaris thing was an actual application that "emulated" a desktop, but who knows....
Any input ?
From Windows I've found the best way to do this is using the Xwin command in cygwin.
Steps:
Install Cygwin, making sure to install X11. (Do this by scrolling to the bottom of the list on the "select packages" screen and click on the word "default" to the right of "X11". Give it a second or two and it will change to "install".)
Then, just run the Xwin command like this:
Xwin -query your.unix.system.name
You'll get a full-screen login window from you unix box. That's it!
Btw, sometimes firewalls get in the way of the UDP protocol for XDMCP. If that happens, look up the port numbers (one UDP outgoing, and one TCP incomming) and unblock them. Other xdmcp troubleshooting tips here.
NX will allow you to use a complete remote desktop environment locally, and most Linux distros already have the server available.
As an alternative to full cygwin install you might want to look at Xming. It is quite a bit lighter and should provide the same functionality.
In Xorg/GDM/LightDM options : "listen" should be activated (disabled by default)
In windows, try Xwin32.
In Linux, try Xnest (windowed) or X with "-query" command.
Be careful: it's slow and everything (passwords included) is transmitted in clear. So keep it on local network, tunnel it in SSH or better don't use it.
I found an additional remote desktop implementation which works quite nicely with LXDE:
x2go
Has clients for Windows, Linux and MacOS X.