When I did the command above, X11 opened. I am perplexed. Did I run it? How can I be sure that I do not run any program when looking at things? I really hate the idea that reading a text file may execute a program. How is it programmable possible to make programs that executes when running a simple cat-command, or similar command?
If you run
file /tmp/:0
you should see that this is not a normal 'text' file but a socket. Aliasing ls thus
ls -F
will help identify such files automatically in your shell.
This sounds like OSX 10.5 behaviour.
launchd listens on a socket '/tmp/launch-xxxxxx/:0'. The DISPLAY variable is set to tell X applications to write to that socket. When an X application opens the socket, launchd automatically starts 'X11.app' to provide the application with a display.
cat'ing the socket opens it and triggers X11.app. I don't think there are any other instances of that behaviour configured by default.
machine:0 is an X display (the first display on 'machine')
I have never seen /tmp/:0 but it might be that your machine is configured so that all unmatched machine names map onto localhost.
You haven't executed anything, the X server will simply try and interpret any commands sent by cat as X instructions. It's like doing cat to an http address
The :0 thing is a socket refering to the X server. Programs use this socket to communicate with the X server (for example to draw a window). Reading from this socket somehow caused the server to activate. The X server must have been already running before you did this command.
Related
I'm coding a Rust app and since it's fairly small and there don't appear to be any stable UI frameworks, I've made it run in the console using println! and whatnot for input/output. However since this program is intended to be used by people directly after downloading from the internet (due to its use case), they're likely to just double click on it instead of navigating to their downloads directory in a terminal and running it from there.
This is a problem because on Linux, it runs in the background waiting for input and looks like it's not working. On Windows, Rust programs do open in CMD by default. (and in fact many of the search results for my question were about disabling this behavior - the exact opposite of what I want!).
So is it possible to somehow make my application open in the system's default terminal? My preferred way would be to somehow embed in the executable to open in terminal (similar to the -mconsole compiler flag on MinGW). Otherwise would it be possible to detect it's in the background and fork it into a terminal? If that's not possible then is it at least possible to detect that the app is not running in a terminal and throw up a message box telling the user to run in a terminal?
My app is cross-platform but I'm OK with writing code conditionally compiled on one OS.
One typical way would be to distribute a program.sh along with your executable. If .sh extension is bound to opening a terminal in their window manager of choice, it would open automatically. If not - it is enough of a hint for running it from the shell.
Without this file you could:
Detect if the program is already running inside a terminal can be done with isatty(). There's a crate for it.
If not, spawn the terminal app process (see process::Command) and relaunch the program with it by passing its path to the terminal command line options. As #Caesar mentioned there's a bunch of popular terminals that you might want to check for presence on Linux. If nothing is found, xterm could sometimes be a fallback.
I just ran a script on a server that generates a lot of output on the command window.
However, now, after running it for roughly 4 hours I want to check all the output, but the beginning of the output has already disappeared from the terminal window. When I scroll up, it is not there anymore.
Is there any way to access this? It needs to be via commands in the terminal because I'm running it on a server.
Thanks.
Best way is to redirect the output to a file & open the file to check for all the output.
You can also redirect the script by running it in background & saving the output to a file. Do let me know what type of command you are running for which I can give you the exact command. :)
if it's a real terminal and not a virtual terminal
you need to recompile your kernel and increase the buffer size of your terminal.
in the .config file of your kernel the parameter you need to increase is
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE
Actually, redirecting I/O interferes with many programs (for instance, changing the output from a tty to a plain file). Use the script program to capture all output from programs run in a shell, with minimal interference.
There are multiple questions that ask about capturing keystrokes, but the solutions provided have some complications.
ncurses termios structure/stty
-Changes the console settings so that SIGSTOP/SIGTERM would leave the setting in effect for the terminal.
X based solutions
-requires X server to be running(not that is is a huge problem, but it seems unnecessary to bring X server calls into a console application)
/dev/input/event*
-requires root
Vim seems to be able to capture keystrokes without root, an X server, and without changing the console settings. Does anyone know how vim is able to achieve this in linux?
Look at TTY raw mode -- there is a ioctl call which allows you to get individual keystrokes -- i.e. taking the tty out of line mode which is the default.
A quick search on ioctl raw give this link which looks ok.
I have this node.js server which, once spawned, expects some input from stdin. The inputs shouldn't be given straight away: I need to wait for some event before giving them (e.g. a connection from somebody). If I give the commands and close the shell, the server shuts itself down. I would like to give the input to the server and close my shell (effectively leaving the server running).
I know that to run a process in background I need to do for example node my_server.js &, but this prevents the input from the command line. I would like to give this input AND then put it in background. Modules like forever puts it in the background automatically without letting me giving the inputs through stdin.
Moreover putting the script in background kills anyways the server when closing the shell.
Any suggestion?
Thanks
I did a quick test just using gedit in Ubuntu 12.04, and it worked.
Start your node app like so "node app.js arg1 arg2" however you want to and hit enter to start the program. Then hit CTRL-z once your program has started running. This gives you the terminal back but stops the process in the background. To let it run in the background now, simply "bg" and hit enter. This will let the process keep running now but in the background.
You can confirm you are still up with the command "ps -ef | grep node" which should show your program still running.
However, this does still leave the node process attached to the terminal window so when you close the terminal window it will close the process. But I think this will get you most of what you seem to be looking for quick and easy.
You asked for any suggestion, so here it is: make your server able to start without user interaction. The simplest way to do it is probably to create a file containing exactly the input needed by the server, then starting it like this:
node my_server.js < my_input.txt &
If the input needed depends on what the server outputs (ouch), use expect(1). If possible, subvert the whole thing and use a module like commander to get your inputs from the command line instead of stdin.
Let say, I access to a server using ssh. In the same time, there is another person accessing that server.
Is it possible to watch what is going on in that person's terminal. Meaning, Can I just watch what he is typing?
If the other person is using the Linux console, you can use conspy.
If you mean that the other person wants you to see his console, you two can use screen to share a terminal. See http://www.gnu.org/software/screen/manual/html_node/Multiuser-Session.html for a full description of how to do it.
I also use an approach similar to what Maze said. This is a unidirectional sharing with read-only for the guest. This is how it works:
1) The host starts the script command writing somewhere where the guest has read access and set the permits as required, for example:
$ script -f /tmp/shared_screen
Script was started....
$ chmod 640 /tmp/shared_screen
$ chgrp shared_group /tmp/shared_screen
The -f flushes the contents permanently so you'll have a very low delay
2) The guest starts dumping the content of the file:
$ tail -f /tmp/shared_screen
In this case -f causes tail to wait on more output from the file. Use ctrl-C to stop displaying the file contents.
You can use the small tool script for logging the terminal into a file. The observing party can simply tail -f that file to follow.
This is a much simpler approach, but it works very nicely for most cases
To capture what Alice types in a terminal,
and then the next day let Bob see what was typed --
without any risk of Bob accidentally typing anything into that terminal --
Alice can type "showterm" ( http://showterm.io ) in her terminal window to start the recording.
To share a terminal so Alice and Bob both see "the same" terminal window and can both type commands into that window,
there seems to be three popular methods:
Byobu, tmux, or screen.
(tmate is a fork of tmux that works just as well, perhaps better).
"How to Share a Terminal Session with Friends" (with Byobu)
"Sharing Terminal Sessions With Tmux And Screen"
"ask Ubuntu: Share SSH Session at login"
"Remotely Working Together on a Terminal Session in Linux" (with screen)
Ubuntu: "HOWTO: Connect to another user's console terminal using 'screen'"
"HowTo Share A Terminal Session Using Screen"
Something nice and easy:
watch -n 1 cat /dev/vcsa1
watch -n 1 refers for the time to refresh.
You can also try "cat /dev/vcsa1"
Well depending on whether its for 'live' or 'ondemand' purposes, you could replay it online with a service like www.playterm.org.
If you want to share a session on a machine behind a firewall or NAT, you can use the open-source terminal sharing program Termbeamer.