I'm confused from the actual meaning of the echoing feature implemented in Linux TTY driver. As far as I know, a pseudo-terminal pair (PTY pair) consists of a PTY master, a PTY slave and a line discipline all implemented in kernel code (i.e. kernel code running in kernel space). From my understanding, echoing is the feature of sending back what is written on the master side ptm so that the process opening such a fd (by opening the PTY multiplexer /dev/ptmx device file) receives back what it has written to. My questions: - is this echo feature implemented within the line discipline kernel code ? - does this echo feature apply only to the PTY master side, i.e. it doesn't send back what is written to the PTY slave side /dev/pts/x ? Thanks.

I'd use socat to redirect the STDIN/STDOUT of the process executing docker run -it ubuntu bash command to a tcp socket in listening on port 32000. root@eve-ng:~# socat -d -d -d EXEC:'docker run -it ubuntu bash',pty,echo=0 TCP4-LISTEN:32000 From another terminal root@eve-ng:~# nc -v 127.0.0.1 32000 Connection to 127.0.0.1 32000 port [tcp/*] succeeded! root@ada2551fd122:/# ls /usr ls /usr bin games include lib lib64 libexec local sbin share src root@ada2551fd122:/# As you can see, the connection takes place and the command ls /usr executed within the container. The problem I'm facing to is that ls /usr like any other command entered is echoed back *twice*. As far as I can tell, the option echo=0 is there to prevent this behavior, however it doesn't seem to work as expected. What is actually going on ? Thanks.

I'd like to use socat to redirect the STDIN/STDOUT of the process executing docker attach to a listening TCP socket on my Linux system. root@eve-ng:/opt/unetlab# tty /dev/pts/2 root@eve-ng:/opt/unetlab# root@eve-ng:/opt/unetlab# socat EXEC:'/usr/bin/docker attach afe29573-0030-4a69-8b3e-c04ededa8db7-0-4',pty TCP4-LISTEN:32000 & 1275378 root@eve-ng:/opt/unetlab# The options for socat are the following: - EXEC:,pty to say socat to start a process executing ` allocating a pseudo-terminal pty attached to its STDIN/STDOUT (socat actually opens the master side multiplexer /dev/ptmx and then the fd for the pseudo-terminal pair's master ptm`) - TCP4-LISTEN:32000 to say socat to open a tcp socket listening on port 32000 Indeed, in another terminal you can check: root@eve-ng:~# tty /dev/pts/5 root@eve-ng:~# root@eve-ng:~# ps -ef | grep attach root 1275378 1210230 0 08:43 pts/2 00:00:00 socat EXEC:/usr/bin/docker attach afe29573-0030-4a69-8b3e-c04ededa8db7-0-4,pty TCP4-LISTEN:32000 root 1275379 1275378 0 08:43 pts/2 00:00:00 /usr/bin/docker attach afe29573-0030-4a69-8b3e-c04ededa8db7-0-4 root@eve-ng:~# docker attach actually attaches to a process running inside the container executing the exec executable, by the way you can see pts/1 is allocated to it (the container indeed was created using docker create -it) root@eve-ng:~# ps -ef | grep exec root 1284441 731051 2 08:52 pts/1 00:00:00 exec root 1284583 1222614 0 08:53 pts/5 00:00:00 grep --color=auto exec root@eve-ng:~# The problem I'm facing to is that connecting to the tcp socket 127.0.0.1:32000 from a telnet client, the login process inside the container (exec) doesn't work as expected. It seems the username typed in (carlo) is repeated again not allowing to successfully login into the container. Username: carlo carlo Password: RP/0/RP0/CPU0:Jun 20 09:00:59.739 UTC: exec: %SECURITY-LOGIN-4-AUTHEN_FAILED : Failed authentication attempt by user '' from 'console' on 'con0_RP0_CPU0' User Access Verification Username: Can you help me in understanding why ? Thanks. P.s. digging into it using strace I noticed that socat actually reads from the relevant fd (of type tcp socket) twice instead of just once.

I have a Python script that is running subprocesses that calls gdb --batch. That script needs to handle Control-C (SIGINT). While one of the GDB subprocesses is running, if I send a Control-C on the terminal, rather than the signal going to the script it goes to GDB. After the GDB job(s) exit, Control-C then correctly will go to the script again. I believe this is because GDB is establishing itself as a controlling terminal. Then when GDB exits the controlling terminal (due to other IO etc) returns to the script. 1. Is there a way to tell GDB not to take the controlling terminal? I looked at the GDB sources and I don't see a way it can be told to do an open() with O_NOCTTY which I suspect would do this. I'm not willing to recompile GDB. Perhaps some hack using a pseudo-TTY somehow? 2. If not, is there a way for my script to "take back" the controlling terminal? Note GDB needs to continue to run in the other process. I suspect I could make a new subprocess, make that the process leader, then do a TTY open, which would make it the lead, then close the subprocess, would that work? I dislike this as a hack. Note I don't want to disassociate the subprocesses from the script's process group. Thanks

I am want to stream a linux terminal to my own program, and as far as I understand this is done by opening /dev/ptmx to start a new pts, I have tested this and this does indeed work (it creates a new file in /dev/pts). But I am not sure how I am supposed to actually read and write to this terminal. Writing directly to /dev/pts/(pts number) I just get an input/output error. Also, am I supposed to open /dev/ptmx and /dev/pts/(pts number) at the same time with the same program. Am I supposed to somehow open a shell first? I find this stuff kinda confusing and I have not been able to find much information except for this man page http://man7.org/linux/man-pages/man4/pts.4.html

On my Ubuntu 20.04.5 machine, I have a Perl script running under userA's account. The script issues this command: sudo su - userB -c "ssh -l userB 10.0.0.1 ls -tr /some/remote/directory" (i.e., SSH to a remote host as userB, and then list all the files in /some/remote/directory) The command works great... except that I'm seeing an error on the command line: me@ubuntu1$ sudo su - userB -c "ssh -l userB 10.0.0.1 ls -tr /some/remote/directory" mesg: cannot open /dev/pts/2: Permission denied Welcome to 10.0.0.1! You have logged in. file1.txt file2.txt file3.txt me@ubuntu1$ What is that mesg: cannot open /dev/pts/2: Permission denied message??? A little Internet research reveals that: > Entries in /dev/pts are pseudo-terminals (pty for short). Unix kernels > have a generic notion of terminals. A terminal provides a way for > applications to display output and to receive input through a terminal > device. And assuming that I'm only reading through my pseudo-terminal: > If a program opens a terminal for reading, the input from the user is > passed to that program. If multiple programs are reading from the same > terminal, each character is routed independently to one of the > programs; this is not recommended. Normally there is only a single > program actively reading from the terminal at a given time; programs > that try to read from their controlling terminal while they are not in > the foreground are automatically suspended by a SIGTTIN signal. That's interesting... but I'm still befuddled why I'm seeing mesg: cannot open /dev/pts/2: Permission denied. I'm still developing my script and have run it several times; I can't remember if I noticed this error message on the first run. Is it likely that every time my script runs, it tries to access /dev/pts/2 every time, but my code didn't properly close the connection or something? Or might this be related to userA using userB to run the command? Pseudo-terminals wouldn't come into play when accessing another user account, would they? Any insight or feedback is welcome, thank you.

I am writing an executable that uses a 3rd party C library (libmodbus if it matters) to communicate via serial device (in my case, /dev/ttyUSB0 or similar to talk RS-485 via an FTDI chipset based USB-to-RS485 adapter). This executable, based on CLI args, can initiate commands (in my case, act like a modbus client) then await a response (in my case, from an external modbus server), or listen for incoming commands (in my case, act like a modbus server) then generate a response. I would like to automate the testing of my executable, without a need for some external device. In other words, I'd like to launch two instances of my executable, where: - The first instance is put into modbus client mode and uses /dev/xxxx for comms - The second instance is put into modbus server mode and uses /dev/yyyy for comms - Set up /dev/xxxx and /dev/yyyy to both act as serial devices that are are essentially the two ends of the same wire. From what I read on pty manpage , I believe /dev/xxxx and /dev/yyyy are the two ends of a pseudo-terminal. Which brings me to my questions: 1. The man page refers to BSD-style pseudoterminals which seem more appropriate to what I am trying to do. - Is my understanding of BSD-style pseudoterminals correct? - If so, is it possible to create BSD-style pseudoterminals on non-BSD linux distributions? In pacticular, I am using debian 10, 11, 12 (and debian based, like Ubuntu 20.04, 22.04) 1. The man page also refers to UNIX 98 pseudoterminals, which are implemented using posix_openpt(). However, even after the subsequent grantpt() and unlockpt(), I can only one one /dev/pts device for the client side of the pty, with the master side being only a file descriptor inside the executable. - Is my understanding (which is loosely based on code like this ) correct? - If so, what tricks may I use to convert the master side file descriptor to an proper /dev/xxxx which is the only API available to get a modbus context 1. Are there other "standard" linux tools for doing what I am attempting to do? It seems like tools like the ones mentioned here are expecting to connect an executable's STDIO to the pty.

I use LinuxMint21, and I go in TTY only when I have an issue with my X session. Today, I went to a TTY, and I saw messages about sysrqd, partially disabled (was not expected), and I have some upgrade to do with fwupdmgr. **I don't talk about the sourced files, like /etc/issue and such, but messages broadcasted like wall only in TTY (like sysrqd when I hit them keyboard shortcuts).** Is there a way or a hack to have those important broadcast messages in my _terminal emulator_? I use xfce4-terminal 0.8.10 TIA.

Let's say I start a program with a non-interactive SSH call (without pseudo-terminal) and exit the session via CTRLC: $ ssh user@server -- sleep 123 ^C This way, the program, in this case sleep 123 for example, is still running on server, even after the SSH session was terminated: $ ssh user@server -- ps -ef | grep "sleep 123" user 12430 1 0 19:28 ? 00:00:00 sleep 123 I am aware of ssh's -t option to have SIGINT sent to the remote sleep instead of the local ssh. But I'm looking for a way to make the remote program stop without having to resort to a pseudo-terminal and specify extra options in the ssh call.

zsh module zsh/zpty seems to work perfectly well on my Linux virtual machine running on Apple M1 macOS machine. But the same does not work on macOS (even on the same host machine). I have tried this with both the build of zsh that comes preinstalled on macOS `/bin/zsh` and one that is installed from homebrew. In my observation, a process is indeed created when zpty command is executed to create pseudo terminal and run a command in it. But after that, writing to process does not work. Here's some example, I entered the following commands one by one in an interactive zsh session:

zmodload zsh/zpty
zpty -b hello 'vim --clean'
zpty -w hello ':e foo'
zpty -w hello $'aHello there from foo file\e:w'
cat foo
zpty -d hello

On macOS `cat would fail with cat: foo: No such file or directory. On Linux you will see Hello there from foo file`. What am I trying to achieve with zpty? I would like to start a process in a pseudo terminal as promised by the zsh manual, and send it input asynchronously. I don't care about the stdout of process. An ideal solution would discard all stdout without being CPU intensive and would not have delay loops. Also, I am not looking for an alternative solution using `expect` or any other external program. Is this a zsh or macOS bug? Can it be bypassed like dtrace restriction can be bypassed like [this](https://poweruser.blog/using-dtrace-with-sip-enabled-3826a352e64b) ? Though I would be surprised if it is SIP (System Integrity Protection) related.

My question is more about the conception and design of pty than how it works. I read chapter 64 (pseudo-terminals) of "The Linux Programming Interface" book and I can't understand why we use a pair of pseudo-terminal (ptmx, pts) and not one. When we look at /dev/tty[1,6], the virtual terminal is emulated and use one file. Why not do the same thing for pseudo-terminal and design an emulated system using one file instead of two?

If run in (pseudo?)text mode as observed under a hupervisor KVM either VMWare, CentOS 8 displays three animated square dots at boot screen: How to disable this screen to see normal text output also during boot?

I'm currently learning about the TTY system, and I want to create a demo application which opens /dev/pts/ptmx which will create a new terminal, and then have a process create a new session which will open this new terminal and be controlled by it. But something is very weird. In order to open /dev/pts/ptmx you must be root. Now, when you open /dev/pts/ptmx, you get a file descriptor which you should pass to grantpts, which will "change the owner and mode of the slave ... device corresponding to the master pseudo-terminal corresponding to fd. The user ID of the slave the real UID of the calling process". But the calling process must be run by root in order to open /dev/pts/ptmx, and only there you have the file descriptor... what gives?

The way I understand it, applications that create a pty (a master/slave pair) can be separated into 2 categories: * terminal emulators (xterm, urxvt, ...), which supposedly produce graphical output * the rest (docker, ssh, tmux, screen, ...), which supposedly produce text output Meaning, the former have to more or less draw on a graphical display. The latter, produce text output (optionally with escape sequences) for the former. And what you supposedly get is a chain of terminal emulators (e.g. xterm ssh tmux docker). Where the segments of the chain sort of translate escape sequences from one language to another. Or to be more precise, they process their escape sequences, and use the terminfo database to translate them to the next terminal emulator. The following image from "The TTY demystified" is probably also in order here:  Now, what makes xterm xterm? Is it xterm that processes escape sequences, or it just lets the kernel do the work? In other words, the xterm terminfo database entry... does it correspond to the kernel, or to xterm? Well, putting it this way, the answer seems obvious. Although I still don't know if the kernel somehow affects the terminfo database entries. What about the other programs? Is creating a pty gives you, sort of, a blank terminal that doesn't process escape sequences, and you're responsible for adding that sort of processing? Which means that the escape sequences you process determines the value of the TERM variable on the other end? Anything I'm missing here? The question is inspired by the following answer , where the author claims that the TERM value doesn't matter.

So I have the following situation: I have a host that exhibits unexpected behavior when using ssh -t combined with tmux. If I call ssh -t my-problem-host tmux non-ascii characters (e.g. €) are displayed as _. If I connect without calling tmux, there is no problem. For example ssh -t my-problem-host bash followed by manually entering tmux is OK, while ssh -t my-problem-host bash tmux is not OK. Other strange behavior outside of tmux: If I use ssh -t my-problem-host vim and enter a special character, I get the special character and a space. If I use ssh -t my-problem-host mc and type a special character, I get two questions ??. I also have this problem only with a single host and would like to know what causes this and how this can be fixed. Essentially ssh -t seems to cause problems, the host seems to have a strange pseudo-terminal.

$ screen
$ stty -ignbrk brkint
$ sleep 10

If I now press Ctrl-A+b to trigger a serial break , why is no SIGINT sent to the foreground process group sleep 10? Are serial breaks not implemented for pseudo-terminals? Or what am I missing?

**Problem:** I have two Linux machines connected with a serial interface. I use ppp to communicate between them (I have to since it is a project requirement). Communication speed is at 9600 bits/s. I need to measure bandwidth used, bits/s, live, i.e. while the system is running. Initially I thought I would use ifstat -btwTWS -i ppp0, since this is what the tools was designed for. However the value that was displayed was way more than 9600 bits/s. It hovered around 12.09 Kbits/s. I did ask why this happening , and the response was that it could be because of a compression. This does make sense. What I need, however, is actual bits/s after compression and before decompression happens. **My initial approach to solve this problem:** Initially I thought to use some sort of a serial traffic sniffer with a capability to display a data rate. I've tried several, but whenever I try to connect to /dev/ttyUSB0 I'm getting a resource busy error. This is happening because PPP is taking over the device. **My second approach to solve this problem:** I want to create a pseudo serial port, connect it to a real serial port. Then PPP will take over pseudo serial port and I will sniff the traffic on a real serial port. Here is the diagram:

--------------------         -------------------------  
|                  |         |                       |
|      PPP         |         |        sniffer        |
|  -------------   |         |   ------------------  |              
|  | /dev/pty0 |---|---------|---|  /dev/ttyUSB0  |  |
|  -------------   |         |   ------------------  |
|                  |         |                       |
--------------------         -------------------------

My understanding is that socat can do that. I've been reading up on this, but I coulnd't find any options that allow me to do that. **So here is my question:** How do I create a pseudoterminal with socat and connect to a real serial port? Is that even possible?

I'm trying to figure out how exactly CTRL^C sends a SIGINT to a process. Let's consider a pseudo-terminal system. I'll write what I know (or think I know lol) and please add/replace where needed: The players are: - Xterm - This is a user space program that reads from the keyboard (using the X window system) and renders a picture to the screen. Every character it gets from the keyboard is passed to the pty master . - User process - the user process that runs as a foreground job of the terminal. Usually when opening a Xterm it runs bash or some other shell program as this user process. - PTY device - This is a character device that the user process is connected to as its stdin, stdout, stderr. Everything that's written by the process to stdout is processed by the TTY driver and its line discipline, and passed as input to the maser side, and vice versa. I don't mind at the moment how exactly the kernel passes the signal to the process once the line discipline/TTY driver understands that it should send such a signal to the process. What I'm interested in is how, after I press CTRL^Z on my keyboard, the Xterm (Which is the process that reads this key presses) passes this information to the pty master ## EDIT Thanks for the answers. I welcome you to response on this thread where I actually tried to simulate this by writing 0x3 to a PTY master and see what happens in the slave. Could you guys respond to that?

In the famous "The TTY demystified ", the following figure is shown: from which it's seemed that the user process is communicating with the "TTY driver", which in turn communicates with the line disciplie. However, in the O'Reilly book : It seems that the user application is communicating with the "tty core", which in turn communicate with the line discipline, and the tty driver is the last layer before hardware. Can someone explain what exactly is a "tty driver"? I want to sharpen my question: As far as I know, drivers are pieces of software used to communicate with hardware. e.g., there's a device driver that knows how to communicate with a disk controller. This driver is the one who actually reads from and writes to the device controller's registers. On the other hand - there are drivers that aren't used to communicate with hardware, such as filesystem drivers, which are basically a software that knows how to organize data in a specific manner. Which type of driver is a tty driver? And where does the line discipline fit in? ## EDIT After further reading and observation in the O'Reilly chapter, it seems to me that what O'Reilly means by "TTY Driver" is actually what the "The TTY demystified" means by "UART driver", while what O'Reilly means by "TTY core" is what the "The TTY demystified" means by "TTY driver". Meaning, the O'Reilly's "TTY driver" is a device driver used to interact with the hardware, whereas the "TTY core" is a kernel-software (hence - driver (?)) used to receive the data from the user process, send it to through the line discipline and to the correct driver (let it be a UART driver or a pty master). Is that correct?

Since terminal emulators are X11 applications, do they receive input from X11Server if we directly type into the corresponding terminal window? In that case why would /dev/pts/N directory exists? Do terminal emulator reject the input events from X Server and directly read from /dev/pts/N?