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
Related
I have maybe a strange question: is there a way to embed something like the Linux command line in an application? Specifically I'm imagining hacking games like Uplink where there's a command prompt in-game that you interact with. They're sometimes done well but often not, since writing a command line interpreter is a lot of work on top of making a game. If there was a way to leverage actual command line tools that would both cut out a lot of work for the developer and also help with immersion (it's a Unix system, I know this!).
It would need to be something like a sandboxed virtual machine, since you wouldn't want it to interact with the real host machine, just a fake in-universe computer. But it'd still be nice to support things like bash.rc, piping commands, foreground and background tasks, and keyboard shortcuts.
I'm imagining something like how Lua embeds in C, where you'd get callbacks in the host application when the virtual linux machine wanted to interact with the console, read/write files or start up threads.
But I don't know if anything like this exists, or even can exist without more effort than it'd be worth? I'm not even sure exactly what terms to google to start researching this.
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.
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 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 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.)