Что отвечает за соединение /dev/pts/10 с stdout/stdin/stderr?

Программа, совместимая с POSIX -, может ожидать наследования файловых дескрипторов #0, #1 и #2 (, также известных программными константами stdin, stdoutи stderr, соответственно )из родительского процесса, в уже -открытом, готовом -к -состоянии использования .

В простейшем случае, когда программа командной строки -в сеансе зарегистрирована на текстовой консоли, без применения перенаправлений, эта цепочка наследования полностью восходит к процессу getty, который инициализировал TTY. устройство для сеанса входа.

При входе в систему с помощью графического интерфейса процесс диспетчера дисплея(gdm/kdm/sddm/lightdm/xdm/<whatever>dm)обычно устанавливает для стандартного ввода и вывода значение /dev/null, а стандартную ошибку — для $HOME/.xsession-errorsили что-то подобное для первого процесса сеанса, и эти файлы дескрипторы также наследуются всеми программами с графическим интерфейсом, запущенными в сеансе, либо как часть среды рабочего стола, либо запущенными с помощью меню или значков рабочего стола.

Например,. SSH, процесс sshd, разветвленный для инициализации сеанса, должен был выделить пару псевдоустройств -TTY, указать файловые дескрипторы stdin/out/errна одну ее половину, а затем exec()изменить оболочку пользователя. Другая сторона этого ответвления будет удерживать другую половину пары псевдо-устройств -TTY и будет обрабатывать шифрование/дешифрование исходящего/входящего трафика между сетью и псевдо-устройством -TTY до тех пор, пока сеанс заканчивается.

Когда эмулятор терминала запускается в сеансе с графическим интерфейсом, он ведет себя по существу так же, как sshdпроцесс при инициализации нового сеанса :он выделяет псевдо -TTY, сам fork()s и один copy устанавливает сеанс, в том числе указывает файловые дескрипторы #0, #1 и #2 на псевдо -TTY и, наконец, exec()на оболочку пользователя,а другая сторона ответвления останется выполнять задачу фактического поддержания визуального представления окна терминала.

Итак, в двух словах, (псевдо? )Устройство TTY было подключено к stdin/stdout/stderr тем, что инициализировало ваш терминальный сеанс, и все процессы, которые могут быть между этим и вашим приложением, просто передавали их по цепочке наследования, ничего не делая вообще к этим файловым дескрипторам, просто позволив им перейти к своему дочернему процессу, как -.

Когда операторы перенаправления используются в командной строке оболочки, так как оболочка fork()является временной копией самой себя при подготовке к фактическому exec()вводу команды, сразу после fork()временная копия закроет соответствующий файловый дескриптор., откройте на его месте вещь, указанную оператором перенаправления, а затем exec()команду, чтобы она унаследовала измененный файловый дескриптор stdin/out/err (s ).

В некоторых системах в стиле Unix -/dev/std*устройства могут обрабатываться оболочкой. Но Linux делает их немного более «настоящими».

В Linux /dev/stdin, /dev/stdoutи /dev/stderr— это просто старые символические ссылки, указывающие на файловую систему /proc:

$ ls -l /dev/std*
lrwxrwxrwx 1 root root 15 Feb  4 08:22 /dev/stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Feb  4 08:22 /dev/stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Feb  4 08:22 /dev/stdout -> /proc/self/fd/1

Эти ссылки создаются, когда файловая система /devна основе udevОЗУ -инициализируется при загрузке системы -. Это обычные обычные символические ссылки, ничего волшебного.

Но /proc— это полностью виртуальная файловая система, отражающая состояние процессов в системе в реальном -времени, и поэтому она обладает несколькими «магическими» свойствами:

• /proc/self— символическая ссылка, указывающая на каталог /proc/<PID>процесса, который ее просматривает:

$ ls -l /proc/self   # the PID of this ls command will be 10839
lrwxrwxrwx 1 root root 0 Feb  4 08:22 /proc/self -> 10839/

$ ls -l /proc/self   # the PID of this ls command will be 10843
lrwxrwxrwx 1 root root 0 Feb  4 08:22 /proc/self -> 10843/

• /proc/<PID>/fd— это каталог, содержащий символические ссылки, имена которых соответствуют файловым дескрипторам, открытым процессом с помощью <PID>,и , указывающий на то, что этот файловый дескриптор связан с .

Таким образом, когда процесс в /dev/pts/10пытается получить доступ к /dev/stdin, символическая ссылка вместо этого указывает на /proc/self/fd/0... и когда осуществляется доступ к /proc/self/fd/0, драйвер файловой системы /procпросматривает таблицы процессов, использует ее для поиска таблицы файловых дескрипторов процесса, который обращается к ней, и представляет /proc/self/fd/0как символическую ссылку на /dev/pts/10... именно потому, что этот процесс в настоящее время имеет /dev/pts/10связанный с его файловым дескриптором #0.

В Solaris 11 устройства /dev/std*являются символическими ссылками на каталог /dev/fd/, что также является «волшебным»:

$ uname -sr
SunOS 5.11
$ ls -l /dev/std*
lrwxrwxrwx   1 root     root           0 Jun 17  2019 /dev/stderr ->./fd/2
lrwxrwxrwx   1 root     root           0 Jun 17  2019 /dev/stdin ->./fd/0
lrwxrwxrwx   1 root     root           0 Jun 17  2019 /dev/stdout ->./fd/1

Здесь драйвер файловой системы Solaris /devреализует волшебство, используя узлы устройств в каталоге /dev/fdвместо перенаправления в файловую систему /proc, как это делает Linux по историческим причинам.