I'm using /bin/sh to execute some commands, but some of those commands require me to have a "graphical terminal" which I don't really know what that means, those commands give wrong output on my software, but correct output on the normal Gnome/KDE Terminal.
I was wondering if there is away to tell the underlying X Window Session that my software is a "graphical terminal"?
As #ugoren said, the DISPLAY variable is what is used to find the X Window System from applications. If X is not running in the background, the variable will be unset.
You can start a new X server using xinit from your script if you cannot talk to the old one; ideally, this would be something like Xvnc (which does not need hardware access).
If I understand correctly you are trying to run application on a remote machine or at least one that doesn't run any X Server. If that is the case you might try to use Xvfb which creates a virtual server which allows applications to connect to it and "draw" windows.
Normally, software that uses X windows relies on the DISPLAY environment variable.
It's value should be something like 10.0.0.1:0.0, where 10.0.0.1 is your IP address (I'm not sure what 0.0 is, but 0.0 normally works).
You also need some X server software to run on your PC, which would show the window.
Related
This one is a pretty strange question of mine so I'll try to explain the best I can.
On a DOS Linux distribution, without having installed any graphical environment, if I start an application which is supposed to have a GUI, will I be able to interact with that window via code?
What I thought is that if KDE/GNOME's role is to graphically represent an existing GUI, I should be able to interact with it but if these graphical environments have an active role in the window creation there is nothing I can do.
You won't be able to run a graphical program without a window manager.
The reason is that the window manager is doing a lot more than just allowing the window to be shown to the user. It comes with libraries and services for constructing windows and components and interacting with them. Without these libraries and services, the program won't be able to start.
The only exception would be if a program contained all the graphical code built into it, and didn't rely on a window manager. Realistically this would only happen for a fairly simple program and in special cases; for instance, Raspbian includes OMXPlayer, which shows full screen video without relying on any window manager.
Quoting (with some adaptation) from https://raspberrypi.stackexchange.com/a/3974 which answers how to start mplayer in X11 without a window manager:
The X server is really usually called X and you can just start it. You can set the DISPLAY number as an argument along with some other things.
You might want to have some sort of session, though, and still go through xinit or such and start X with startx. You can use .xinitrc or such as a script and simply not start a window manager there. You will need a "magic client" as the last command that stays running so X doesn't terminate immediately. In a traditional "failsafe" session, that was an xterm. If you know what to launch and launch once only, it could be that program or any UI/wrapper that does the launching for you. When the last ("magic") client in the init script terminates, X terminates.
If all you want to do is play video, you might see if you can run mplayer with directfb instead and skip using X11 entirely.
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 am having some problems with launching firefox from a Linux daemon written in C.
When I launch firefox on the machine itself (via terminal) from the command shell using /usr/bin/firefox it works OK and a firefox browser window lanunches as it should.
However if I try this within my C daemon using system("/usr/bin/firefox"), firefox launches its process in the terminal but the browser window is not opened?
A similar thing happens when I try to do this using remote terminal acces. It's something to do with telling the system to open firefox in window mode rather than trying to open it in terminal mode - but I dont know how to specify this using bash commands?
I am using Lubuntu 11.10 in my Linux System.
Any help is most appreciated.
There's a reason I asked why you're attempting to do what you want. I didn't want to get into great details in my comment.
Firefox on Unix is an X-Window process (most of the Linux/Unix desktops are based upon the X11 protocol which is the heart of X-Window). What X-Window does is separate the display of the program from the process running the program. For example, I am now running Firefox from a Linux box at work, but the Linux box is actually displaying the Firefox browser window at home on my Mac.
In order to do this, I had to:
Run X11 on my Mac. The X11 program creates a default X11 client display called 0.0 which pretty much says the first screen and the first instance of X11 running (computer geeks like counting from zero). The process runs in the background on my Mac. In a certain sense, it's really a server process and not a client because it's waiting on port 6000 for a client X11 process (Firefox) to tell it what to do.
Before I run firefox, I have to tell my Mac's X11 process that I grant the X11 server running Firefox to be able to display on my X11 client process. Otherwise, you can imagine someone spamming another person by continuously popping up Windows on their display. You can use the xhost program to do this.
In order to run Firefox on the Linux box, I have tell the Firefox process what X11 client I'm running it on. I can do this by setting the DISPLAY environment variable to something like "10.0.1.33:0.0". This means the X11 client is running the the machine on IP address 10.0.1.33, and I want you to use the first screen, and the first instance of the X11 client on that screen.
Now, I can run Firefox on my Linux box, and the display will display on my Mac.
The problem you're running into is that there's simply no X11 client when you're starting FireFox as a daemon process. An X11 client is associated with a user and a display of some sort. The display could be a virtual display, but there's got to be an X11 client that's running and is addressable in some way, so the process knows where to display the output.
By the way, you said daemon which has a very, very specific meaning in Unix/Linux. A daemon is a process that runs in the background and usually has a service (and a port) associated with it. For example, there's an FTP daemon called ftpd, the mail server uses the sendmail daemon, ssh has the sshd daemon. Daemons have no display associated with them.
However, it looks like you might be using the word to mean launching Firefox via another process. Is that true? If so, you'll have to make sure that Firefox knows the X11 display to use (there's a command line setting to use to specify the display), and that your X11 client (your login session) has given permission for another process to update your display with the program window.
Can you please explain what you're trying to do in a bit more detail? If you simply want to download a file from a remote http server (which of course is running the http daemon process called httpd), you should use curl or wget which don't require a display and are way simpler to use. If you're trying to do something else, let us know exactly what it is.
Firefox needs to know which display it should open on. When you run it from within a gui, even through a terminal emulator, the DISPLAY environment variable is set to the appropriate value. When you launch from the daemon, try system("/usr/bin/firefox -display=:0").
Make sure that the DISPLAY environment variable is properly set in your daemon to refer to the X server that you want your firefox to use.
If the daemon is run as a different user account than the user account that "owns" the X server that you want to use, you will also need to use xauth(1) to configure the authentication token to grant permission to use the X server.
Often times, it is far easier to use ssh -X to tunnel X and properly configure the xauth(1) tokens in one go than try to manage xauth(1) tokens yourself. Maybe adding ssh -X into your environment would be suitable, maybe not. (I've even used ssh -X root#localhost before when I needed to run an X client as root and didn't want to bother with configuring xauth(1) manually. ssh(1) is just so much easier.)
I use a chroot development environment for developing software for devices. The chroot dev environment isolates the rest of my system from my build-system hacking. The chroot environment is text-based, but I prefer to use a graphical text editor. Right now, I keep one terminal chrooted into the dev environment to build packages and one terminal pointed at the chroot environment from the outside to edit files.
I'm tired of constantly switching back and forth between these terminals, but I don't want to install X and Gnome on my compact dev environment for obvious reasons. I need a way to forward certain commands to the exterior environment, but I can't think of a simple solution. How can I execute a command on the exterior system from within a chroot environment?
Yes, SSH can be used, but without X forwarding, because you want to run the app outside of chroot, not inside. This means you have to tell the app where is its X server, because SSH won't do it for you. It is done by setting DISPLAY environment variable prior running any X app to the same value as your non-chrooted terminal has, usually it is:
export DISPLAY=:0
You could SSH into your own system, enabling X forwarding, and set it up with keys so no password is required. At minimum, something like:
ssh localhost -c my-graphical-editor
When an account is chrooted, everything that you need has to exist in the chroot / environment. That means /usr, /opt/, etc., has to be "local" and populated with whatever code is required. Graphical interfaces typically require a boatload of support code.
You may personally prefer a graphical interface but is it necessary? Or more correctly will it compromise the jail; make it easier to break out of jail?
You can su back and forth pretty quickly...
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.