This program can start processes inside a pseudo-terminal, which can be accessed through a Unix socket, TCP or even raw ethernet (using the ethernet protocol 0xCACA). The programs can be linked to the current terminal, or they can be unlinked like in nohup. But even in this latter case you can connect to them using the mentioned protocols.
tm can also start programs as if they communicate through pipes instead of terminals, and this can be quite useful for remote-controlling applications.
More than one client can connect to the served pseudo-terminal, either using tm as a client or telnet for TCP. You can choose if they are only allowed to read, or they can also contribute on input.
Download the latest version (GPL 2+ licensed): tm-0.4.1.tar.gz - v0.4.1 - ChangeLog
Look at the version repository if you are interested in its development. If you can send any bug report, please do that at the mail address at the bottom of the page. I'd like this program to have as few bugs as possible, sure!
tm -N 2 -p 3000 -t -x -w vim
Two [-N 2] users will be able to telnet to the port 3000 [-p 3000], and get the same vim terminal [-t] interface as you. They will be able to use vim [-w], not only look at it. The size of their xterms [-x] will be set accordingly to the size of your terminal. A nice feature of xterm!
Attention! vim programs the vt100/xterm input/output codes at start. If the clients don't receive those codes, they won't be able to use the Cursor Keys effectively, for example. In that case, you may start a bash in tm, and when the clients are connected, start vim.
Start a remote bash putting this in your start scripts:
ifconfig eth0 up tm -e eth0 -n -w bash &
Then you can connect to it using another computer (as root), typing the MAC address of the serving host:
tm -e eth0 -c 00:14:85:16:B2:32
And you will have a non-terminal bash answering your requests. Don't exit from it, because the tm server will end.
Start a mplayer allowing remote commands with:
tm -w mplayer -slave voice_recording.mp3
Then you can send orders as simple as these:
echo pause | tm
Make your xbindkeys to map to these commands, and you can have a good control of your music playing. In fact I mapped pause to F1, and go backwards 5 seconds to F2, and I use this for transcription of voice recordings.
If you run a telnet client inside tm, you can use a tm client to send uuencoded streams. You can look at a Youterm podcast for that.
Imagine you want to run the program XXX, which does a lot of debug output in stdout. Even without running it through tm, you will be able to access the logs only when you connect to it.
XXX | tm cat > /tmp/total_log.txt
You can redirect to /dev/null or use tm's -n [nohup] if you don't want to store all the debug info. In any case, you can run a simple tm command with no parameters, and you will be seeing the debug info since the connection. Close tm (Control-C) and you will not see the info until a new connection is made.
Here you have a copy of the help for v0.4:
tm v0.4 - terminal mixer, Copyright (C) 2007 Lluis Batlle i Rossell
usage: ./tm [opts] [appcommand] [param1] [param2] ...
If you give _appcommand_, it starts the application and
serves it through a Unix socket on $TM_SOCKET or /tmp/tm-socket.UID,
unless '-p' is used.
Without _appcomand_, starts a the Unix socket client.
options:
-h Show help.
-P Run the child as connected to a pipe (default).
-t Run the child as connected to a terminal (raw mode in client).
-n Unlink the program from the terminal (as 'nohup').
-N MAX Serve at most MAX sockets for each transport (1 default).
-w The remote clients can write to the application.
-C The remote clients end will close app's stdin.
-p NUM Listen to tcp port NUM for 'telnet', and not listen to any
Unix socket.
-E Echo remote input to the server terminal.
-e dev Also serve/connect using raw ethernet, device 'dev'.
-c adr Connect to address (MAC if eth).
-x Send xterm's resize control string to clients.