By now I have now spent at least 10 hours trying to get my head around the famous blog post by Linus Akesson, and Im still struggling. So let me ask my doubts about tty/ptty as a series of short questions.
1) Is the tty/ptty in user space or kernel space?
2) What is tty/ptty's connection to devices or drivers or some numbering or something?
3) The tty seems to be linked to something called the controlling terminal of a process, What is the relation and is every process related to a terminal?
4) On the whole I still dont understand where the heck this terminal concept fits in. A process wants to read something from the stdio, cant it simply do it from the required device file. What exactly is the problem that the tty intends to take care of?
5) I read somewhere that there are attempts to move the tty from the userspace to the kernel space. Is the tty simply a historical residue than a strong design feature.??
A clarification (which might answer some of your questions):
I think you meant pty (and not ptty) which is pseudo-tty/pseudo-terminal.
A tty (/dev/ttyx) - stands for teletype - is the original terminals (used a line printer for output and a keyboard for input!). A terminal is basically just a user interface device that uses text for input and output.
A pty (/dev/pty/n) is a pseudo-terminal - it's a software implementation that appears to the attached program like a terminal, but instead of communicating directly with a "real" terminal, it transfers the input and output to another program. It's the end point of telnet/SSH or even the GNOME terminal.
For example, when you ssh into a remote machine and run ls, the ls output is sent to a pseudo-terminal, the other side of which is attached to the SSH daemon.
EDIT:
As far as I know, the tty and so pty, are usermode. BUT they represent terminal-driver. What I mean is: the device file /dev/tty1 is the first virtual console. Most code lives in drivers/char, in the files tty_io.c and n_tty.c and vt.c (kernel source). In contrast to character devices in order to open those files tty_open routine is called, and trust me, it's way messier than opening a character device...
Tty/pty stands for terminal drivers mentioned above but they stands for serial ports (the"numbering" you said). I know very little about it so I don't want to say incorrect data... but you can search the net about it (or someone else can continue from here)
EDIT2:
You have changed the question so now it seems like I spoke out of context...
Anyway, tty has many different roles even nowday. Terminal driver is the way user-kernel can "communicate". There are some techniques such as terminal drivers, character device etc.
If you still have a question please comment and don't change the whole post....
Related
I spent several decades using Digital Equipment Corporation's VMS operating system, and one of the things I really miss is the terminal driver's 'read-with-prompt' functionality.
It would display the prompt and position the cursor for input, as you'd expect, but the prompt was immune to things like CTRL/U, CTRL/R, and CTRL/W. It was an attribute of the read operation, and every time the terminal driver was ready to read from the terminal with this option, it would show the prompt. The user couldn't erase it, so if it went off the screen he'd still know what was being requested.
This is one of the few things that I think VMS did better than U*X -- unless there's a Linuxish way of doing this.
So far I've never found it, but maybe I'm just not looking in the right place.
Is there a way on Linux to read from a tty with a persistent prompt?
Thanks!
I found this awesome text explaining a lot about TTY devices. It focuses in the relation between a TTY device and a shell (and its spawned jobs). But it says little about the relation between the terminal emulator and the TTY device; and now I'm wondering about that. I googled, but I could not find the answers...
1) What kind of input logic is the terminal emulator responsible for? It just sends each character code (received by window event) to the TTY device, or it does a more complicated processing before/during the transmission to the TTY? And how these character codes are sent to the TTY device? Via file?
2) After a foreground process calling write() to the TTY device file, a.k.a. stdout/stderr, what happens? How this data reaches the terminal emulator process, so it can be rendered? Again, via file?
3) Is the terminal emulator responsible for "allocating" a TTY device? TTY devices can be created "on the fly" by the kernel, or is there a limited number of available TTY devices the kernel can manage?
First of all, answer yourself what a terminal is.
Historically, terminal devices where some dumb devices that transformed output characters from programs to visible drawings in some output device (a printer or a cathode ray tube) and send input characters to programs (produced at a keyboard locally) through a serial line.
From that perspective, a terminal emulator is some software application, normally running at a computer that has not been designed to act as a terminal device to make it behave as such. Normally, this means it will be receiving input from a serial line to output to the user (for example in a specific window on the screen) and will process user input on that window and send it to a remote computer for processing in the program running there.
By contrast, tty lines were serial lines used to send and receive characters. In UNIX, they used to have a common driver, that did some processing to the received characters from the actual terminal. For example, the unix driver collects all characters, allowing some editing via the use of the backspace key, and only make this data available to the program running on the computer after the user (the terminal) has sent the RETURN key.
Some time ago, the need to have virtual terminal devices (devices that don't have an actual terminal behind, but another program instead) where needed to run several programs that used to program the connecting device (for example, to not echo password characters back to the terminal, or to do character by character input, instead of line by line) and to allow the driving programs in the virtual TTY program to act upon these programmings.
Virtual terminal devices come in pairs and terminal emulating programs get the master side of the virtual terminal, running the actual program in the slave part (for example a login shell to allow a windows based pseudoterminal)
Now the answers to your questions:
1) Terminal input logic is managed at the virtual terminal driver of the slave device, as if the program running on it has complete control of character mapping or line/raw input. By the way, the program attached to the master side, only gets the raw characters, without any interpretation, so it can, for example, send a Control-C character to interrupt the program running on the slave side.
2) when the program running at the slave side does a write, this write goes through the tty driver, that makes all the asumptions of line-discipline (for example to add a CR char before any LF character to make a CRLF sequence, in case of terminal cooked mode of operation) the program running on the master side will receive the raw characters (even, for example a Ctrl-C written by the program) On input, tty device converts input character (case of a Ctrl-C) and sends the proper signal to the group of processes attached to that pseudo terminal.
3) Historically, the terminals appeared as device pairs (as one specific kind of terminal character device driver), and as such, they had inodes with major/minor number pairs. This limited their number to a properly configured administration value. Nowadays, linux, for example, allows dynamic allocation of devices, making it possible to allocate device pairs dynamically. But the maximum number continues to be bounded (for eficiency and implementation reasons)
Question:
If I have a pty or tty master/slave pair, what can I not do with it if I only have the slave node's file descriptor? Or, put another way: what can I only do if I have the master node's file descriptor?
My Current Understanding:
I grok the "typical" relationship of a terminal/console/SSH having the master end for interfacing with a human, and one or more program (e.g. a shell and its children processes) being on the slave end. And I (loosely) grok the more unusual(/archaic?) usecases like using a TTY for other kinds of data links, like PPP. This question is not a "I don't get this TTY business" question. I'm asking about the ("low-level"?) "API" stuff: e.g. is there any termios/ioctl manipulations or other programmatic changes to the TTY pair that cannot be accomplished if you don't have access to the master FD?
I guess the obvious ones are:
I can only read/write from the master end if I have the master end's FD.
grantpt/unlockpt/ptsname can only be used on the master end's FD.
Anything else?
I've been on/off reading some man pages and experimenting on my Linux machines: the basic stuff one would want to do with a pty (e.g. stty columns 78, etc) seems to work on "either end". But I would suspect there's stuff only a process holding a file descriptor of the master end can do (especially because the master-slave name dichotomy suggests some unilateral control/dominion). And of course since I'm only testing on Linux, there's possible behavior differences between various versions/configurations of Linux and vs. the Unixes, so I don't want to assume that what I'm seeing is portable.
Motivation
(In case someone wants to know why I want to know)
General knowledge/curiosity.
I'm not in love with the current selection of command line tools for working with ptys. Without getting into the details, I've looked at reptyr, ptyget, expect/empty, screen/tmux(/neercs? the one with reptyr-like feature), dtach/abduco, and none of them hit my sweetspot of minimalist versatility. I'm trying to become more informed so I can better evaluate existing solutions and/or better design my own tool(s) to scratch my particular itch.
Thanks to StackOverflow's related-questions suggestions and other online searching since asking this, I've found a (partial?) answer:
Enabling or disabling packet mode on a PTY in Linux can only be done if you have the master FD [See TIOCPKT at this manpage]
Getting the Session ID associated with a TTY in Linux can only be done if you have the master FD (unclear if this is expected/intended behavior) [See TIOCGSID at this manpage]
Re-sizing the TTY is only portable from the master FD in practice (a terminal emulator might resize the TTY when it's resized, but an application with just the slave FD has no real certainty that the master size resizes accordingly, or that the terminal driver will even accept a resize from the slave end). [Source]
There is a trick for telling if the slave end of a TTY is opened, that you can't do if you don't have the master FD. [Source]
I'll try to keep coming back to edit this as I learn more.
I've got a quick question, but I can't find an answer.
Is it possible in linux (or in python) to see if an external usb pen drive is idling?
I need to know this for a python script I'm writing.
I need to rename a folder on an external usb pen drive as soon as nothing is writing to it.
edit: I know there is lsof command to list open files. 'lsof /theDir' only works half. It works OK when the process copying to the USB is still running. But when the process stops, lsof shows nothing. But the OS is still writing to the USB from its buffer.
You can check if all I/O has been processed by having a look at /sys/block/<dev>/stat.
The ninth column contains the number of I/Os currently in flight. Check https://www.kernel.org/doc/Documentation/block/stat.txt
Once this numner is zero the device should be idle.
To force all buffers to be written immediately you could execute sync and wait until it returns.
Nevertheless be aware that you have a race condition here if you are not controlling the writing - after you decided that the device is idle some other process could start writing to it.
I have a program (a bash script actually - console only) that scans or makes copies, etc based on user input. It asks questions such as how many copies would you like to make, etc and then scans the document, and prints it to another printer. The program runs in a loop so it's always there when a user passes by, and using a keyboard or number pad you can easily operate it. It basically makes a simple scanner/printer combo into a complex multifunction device.
I can leave it running on a dedicated system just fine, but to save electricity and resources, I would love to have it run on a computer someone else is already using. There is a user who has a laptop on the same desk as the scanner, and I was wanting to have her be able to do her thing in Xorg, as per usual, but have this little program running on an external monitor. That part is easy, but separating input is not. First of all the window has to be in focus, and then any input from the laptop keyboard OR usb keyboard is sent to the program, obviously.
I can think of one way to do this: using virtualbox, I can run a virtual machine without X, have it permanently ssh into the host OS (to which the usb scanner is connected) and I have virtualbox grab the usb keyboard input. But that seems excessive.
Does anyone know of a way to map input from a specific keyboard to a specific program or tty?