How are the standard file descriptors implemented?

Fri Oct 9 00:47:14 EDT 2020

On Wed, 07 Oct 2020 08:11:17 +0200, Sebastian Fricke said:

> - The standard file descriptors are an abstraction layer in between an
>   output device like a monitor and an input device like a keyboard. In
>   the old days, these were configured directly to the terminals.

There's "in the old days", and then there's the age of myths and legend, which
some of us were already around for. :)

Yes, files were configured to terminals. Unless they were connected to a pipe
to another program, or to a file, or to a network socket, or... In other words,
only configured to terminals by default, if you were running from an interactive
source like a terminal or console.

Redirection to a file was there from pretty much the beginning of Unix.
https://en.wikipedia.org/wiki/Everything_is_a_file

Pipes date back to 1973 or so.. https://en.wikipedia.org/wiki/Pipeline_(Unix)

BSD 4.2 brought us sockets, although I admit not being sure when bash sprouted
the /dev/tcp and /dev/udp pseudo-devices. (And also brought loads of fun when 4.3
showed up with a different concept of broadcast addresses, meaning that a 4.2->4.3
upgrade was a flag-day for the entire subnet... or else. :)

And I remember more than one security exploit against programs that assumed
that stdout was connected to someplace rational, which led to hilarity and hjinks
if you invoked the program with file descriptor zero closed, it would open some
security-relevant file like /etc/passwd (possibly inplicitly via a call to getpwent() or
similar, and then invoke some other program, which now had fd 0 stdout connected
to /etc/passwd. (vipw got bit by this, among other programs...)

> - Who creates that device /dev/pts/4 ? I was currently not able to
>   locate this information.

The Nth program to open a generic pts device. It can then be fed to dup()
to create copies, passed across a fork/exec, or pretty much anything else
legal to do with an open file descriptor. In a GUI environment, it's probably
xterm/Gnome-terminal/etc...

> - How is that device connected to my keyboard/monitor?

Depends.  if you're on a virtual console, it's probably using /dev/ttyN instead.
If you're running an X-based GUI, it gets complicated. :)

Normally, xterm or gnome-terminal or whatever, creates a pty,
sets up fd 0 1 and 2 to point to it, opens up its own file descriptors for
the other end of the 3 pipes, and then fork/execs bash or whatever program.
So if bash or a child scribble on stdout, xterm then reads from the other
end of the pipe and then goes through a *very* long and ugly process
to map that to pixels on the screen. input goes through an equally convoluted
process from a keyboard event being read by the X server (usually via the evdev
driver in most modern distros), then passed as an X event to xterm or
gnome-terminal, which then reads it and synthesizes a character input
and pushes it down the pipe to the bash or vi or whatever is currently
the process reading from the terminal.

Meanwhile, bash does its own games when setting up to run a program, in order
to get any redirections set up.

> - Could I maybe create a simplified version, which just utilizes a file
>   for STDIN, STDOUT, STDERR. That are created by the init process and
>   inherited to all child processes?

% your_command_here < your_stdin_file > your_stdout_file 2> your_stderr_file

Done. Don't make it harder than you have to.

>   Maybe I could then redirect the
>   keyboard output to the STDIN file, the STDOUT file to the monitor
>   device etc.

That's actually more complicated than just directing the file to wherever in the first place.
(How complicated?  The xterm source famously contained the comment "Here there be
dragons. You are not expected to understand this" in the section of code that set
up the ptys for the child process's initial fd 0/1/2.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20201009/5d611aab/attachment.sig>