tty [OPTION]...
Step 2
The ANSI escape sequences for setting the foreground and background colors of text are what's limiting things here.
From memory these sequences look something like escape [ 01;34m There are codes in the 30's for foreground and I think 40's for background.
So I don't think there's any way to achieve what you're looking for.
The ttys are not just input/output devices. They also do a special job of acting as the controlling terminal for a session, like sending signals (Ctrl+C). /dev/ttyNN are virtual consoles, which are full screen displays on the monitor.
The terminals start from /dev/tty1. You could switch to these consoles, usually, by pressing Ctrl+Alt+Fn keys.
e.g, Ctrl+Alt+F1 takes you to the first virtual terminal. Nowadays, most of the Linux distributions run the X server from the tty1. So, pressing Ctrl+Alt+F1 may not have an effect.
$ ps ax | grep Xorg | grep -v grep
1504 tty1 Ss+ 44:57 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-rfsWyA/database -nolisten tcp vt1
Ctrl+Alt+F2 will take you to the second terminal. Usually the distributions run a login program(agetty) on the virtual terminal.
$ ps ax | grep tty2 | grep -v grep
31865 tty2 Ss+ 0:00 /sbin/agetty tty2 38400
The login programs provide you a login prompt and lets you login with username/password. The init scripts decides, where all the login program will be run. So depending on that you may or may not see a login prompt on, say tty9. To go back to your GUI interface, press Ctrl+Alt+F1(as in example output above).
/dev/tty0 is a special device, which points to the current terminal. So, irrespective of where you run it from(any virtual console), anything read from/written to tty0 goes to your current terminal.
The second column in 'ps ax' also gives the controlling terminal of the program. For some programs, like daemons, you may see that the column is '?', which means they are not bound to a terminal.
/dev/pts/0 etc are psuedo-terminal devices, which are not attached to the system display. for e.g, terminal you get when you open a gnome-terminal or any other GUI terminal. These are client-server based approach where client side will be exported to programs, like bash. The data send by the program to the pseudo terminal is sent to the 'server' side (which is usually monitored by another program, like gnome-terminal). The controlling process (server side) determines what needs to be sent to the terminal, which is eventually seen by the client. These devices help you to open multiple 'GUI terminals' without any limit on your system, still providing the same old terminal like controls(ioctl(), colour setting, Sending signals [Ctrl+C] etc. ).
*NIX is by design a multi-user system, so there is not going to
be an issue by logging in multiple times on available consoles.
This was "the way" to be productive before the advent of
mulitplexing terminal programs such as screen. I
still know individuals who run *NIX workstations with no
X-windows, preferring to use multiple consoles, and usually
screen, to perform their work.
The only thing to be aware of is that by default the consoles are not password protected once you log in. Anybody could walk up and begin executing commands as your logged in user.
Yes, you can using the chvt command. This needs sudo privileges to run.
CHVT(1)
NAME
chvt - change foreground virtual terminal
SYNOPSIS
chvt N
DESCRIPTION
The command chvt N makes /dev/ttyN the foreground terminal.
(The corresponding screen is created if it did not exist yet.
To get rid of unused VTs, use deallocvt )
The key combination (Ctrl-)LeftAlt-FN (with N in the range 1-12) usually has a similar effect.
You can find the virtual terminal you're currently on via the fgconsole command. This too requires sudo privileges to run.
If you don't like screen or gpm, your alternatives are quite limited. The other options I can think of are:
Run terminals under X, maybe using a tiling window manager for a minimalist, console-like look.
Run a *BSD instead of Linux, which will let you use sysmouse instead of gpm. I hear it's better, and my limited BSD experiences suggest that it may very well be better, but I don't know if it's better in the area of clipboard support. Sounds like you mostly just don't like your trackpad though, which is probably unfixable without replacement.
Use pipes, named pipes, scratchfiles, etc. For example, most unix editors will let you process selected text via normal command line scripts, which could be setup to save the selection to ~/.clipboard, for instance. Running commands that input text (cat ~/.clipboard) should be even easier.
Use an editor that supports multiple files, and copying/pasting across them. vim does, and emacs does too, I'm sure.
You can only run a virtual console (VC) on a tty device that exists. By default, Debian Linux ships with 64 such device files (/dev/tty0 through /dev/tty63). Other reading suggests that the limit in the kernel by default is 256 of these, so it may be possible to create up to /dev/tty255. If you need more than that, you'll probably have to recompile the kernel.
The more practical limitation, however, is how do you actually use that many VCs? LeftAltF1 through LeftAltF12 will only get you up to VC 12 on most keyboards (10 on others). To extend this number, most Linux systems ship with RightAltF1 through RightAltF12 mapped to VCs 13 through 24. Beyond this, you can do your own keyboard mapping, which you can read about here if this is something you're interested in doing.
You can also use Altleft or
AltRight to cycle through all VTs. And the
chvt command can be used to directly change to any
active VT.
Very interesting. I have not seen that done before... the way you have it working anyway. I confirmed on my computer that your technique seems to randomly decide if its going to send the character over to the other terminal.
I've seen something similar done... which works a bit differently. You can directly send text to another terminal with this:
echo "hello" >/dev/pts/1
where /dev/pts/# is the number you get when you use the tty command on the remote terminal.
One solution is changing the init system, so a getty process gets a tty and invokes your script. Your script might then initialize a named pipe (aka fifo) and redirect stdin to it.
Then you can login via ssh and read from that pipe.
The problems were:
Now I can have a shell over all things socat can support and can
start vim/screen/ssh, interrupt ping with ^C, end
cat with ^D and do everything else in that shell.
The problem you have with running the setup you mention is the keyboard. The keyboard will be captured by the x server running on your primary display (high-res). You will not be able to switch to the other terminal if you would like to type something in it.
Even if your secondary monitor is low resolution, you could run
an xterm session on it that's separate from your main x screen.
You will want to setup the 2 displays as completely different
screens (not using xinerama). You will end up with
0.0 and 0.1 displays. Your primary
display would be the 0.0 whereas your DISPLAY
environment variable will be as follows:
export DISPLAY=:0.0
This configuration will allow you to move your mouse between the
2 screens to choose where your keyboard input will be passed. In
your .xinitrc (in your home dir), you could then do
something as follows:
#!/bin/bash
xsetroot -solid black
xsetroot -display :0.1 -solid darkblue
xterm -display :0.1 -fn 9x16 -geometry 86x36+1+1 &
startkde
This would start by setting the background of your primary display to black. Next it will set your secondary display background to darkblue (I use this color because I use my secondary screen for watching movies). Next line starts an xterm on your second display with a preset geometry. You will want to adjust the geometry to fit your screen the best for you. You cannot specify pixel width and height because the geometry for xterm measures in characters. If you choose the 9x16 font size as in my example and your secondary screen resolution is 800x600, you would do the following math:
font size = 9x16
screen size = 800x600
xterm width = ( 800 / 9 ) = 88.888
xterm height = ( 600 / 16 ) = 37.5
You want to round the number down some, especially for the width
since you need to account for a scrollbar. You will not have a
window manager on the secondary screen so there will be no xterm
window title (unless you choose to run something light on the
second monitor such as twm or fvwm).
Basically, you will have to play with the numbers til you get it
how you want it.
The last line in the .xinitrc file will launch the
main window manager on your primary display. You can change this
to gnome-session or whatever launches your favorite wm. You could
also modify the existing .xinitrc for your
distribution if you wish to preserve the ability to choose your
window manager during login. There should be a skeleton file in
your /etc/X11 for using as a base.
Print the file
name of the terminal connected to standard input.
-s, --silent,
--quiet
print nothing, only return an exit status
--version
output version information and exit
Copyright © 2012 Free Software Foundation, Inc. License GPLv3+:
GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute
it. There is NO WARRANTY, to the extent permitted by law.
Report tty bugs to bug-coreutils[:at:]gnu[:dot:]org
GNU coreutils home page:
<http://www.gnu.org/software/coreutils/>
General help using GNU software:
<http://www.gnu.org/gethelp/>
Report tty translation bugs to
<http://translationproject.org/team/>
The full documentation for tty is maintained as a Texinfo manual. If the info and tty programs are properly installed at your site, the command
info coreutils 'tty invocation'
should give you access to the complete manual.
Written by David MacKenzie.