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.