Что вы подаёте на вход в поток ошибок?

Обычно отдаю объект Exception с параметрами.

Можно, но не нужно, это какая-то замшелая совместимость. Использовалась, ЕМНИП, вот как раз потому, что в bash очень легко переопределить stdin, а спросить у пользователя иногда что-то все равно хочется, даже когда ты в середине пайпа. А раз уже понаписали такого софта, то закрепил в стандарте. Сам на это лучше не полагайся и не мудри.

Это наверно хороший способ определять интерактивную сессию: если мы в терминале то stderr будет r/w, а если это демон с перенаправленным stderr то он будет write-only и попытка чтения из него вернёт ошибку. Можно даже специальных проверок не делать: спрашиваем у юзера, читаем ответ из stderr и ошибка EBADF это один из вариантов ответа.

https://unix.stackexchange.com/questions/452809/how-and-why-use-stderr-for-both-reading-and-writing

man isatty посмотри перед этим

Да я понимаю. Просто этот рудимент скоро уйдёт. Лет через 10-15.

Будут другие принципы отработки событий.

1) это дополнительный системный вызов

2) stderr может быть проброшенным куда-то сокетом с интерактивом, но без виртуального терминала

Кто я такой, чтобы тебя останавливать.

не мудри.

Почему же?

Я может хотел уже спросить, как обрабатывать stdin и stderr в двух разных потоках параллельно, чтобы ввод по каждому из них не блокировал ввод по другому...

https://stackoverflow.com/questions/48443136/c-how-read-function-read-from-st...

Меня только напрягает, что дескриптор всего один. Как ему в баше указать, что читать из одного файла, а писать в другой?

$ ./myprogram 2<input.stderr.txt 2>output.stderr.txt

… никак?

Тебе дескрипторов жалко? Сделай 3<moar.input и не мудри.

Какой смысл вообще спрашивать совета, чтобы потом делать невесть что? Просто делай.

А что, нормально, когда утилите dd надо передавать сигналы при помощи kill для того, чтобы она текущий прогресс вывела? Лучше бы она stderr читала.

Нет, но твой вариант ещё хуже. Что будет, когда их в пайпе буде несколько?

Это проблемы синтаксиса баша, а не утилиты. Утилита должна решать свою маленькую задачу. А баш должен уметь перенаправлять потоки отдельно у каждой части пайпа:

$ ./myprogA 2<test.errA.txt | ./myprogB 2<test.errB.txt | ./myprogC 2<test.errC.txt

Это всё круто, но зачем ты свои кастомные редиректы в stderr пихаешь?

Нет, не нормально. В нормальных системах (FreeBSD) сигнал dd передаётся с помощью Ctrl-T из терминала. И не только dd, там многие утилиты поддерживают вывод статистики по SIGINFO + ядро тоже выводит.

Ничего не понятно. Баш умеет, как это со статусом поможет? Предполагается, что я создам по FIFO на каждый dd?

Это тактические вопросы, моё дело стратегия. Пользователь возьмёт три экземпляра утилиты screen и подключит к каждому из dd свой.

Так он SIGINFO с помощью kill и передает. Потому что не RTFM

^T видите?

$ stty -a
speed 38400 baud; rows 35; columns 180; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

Я - нет.

Так и должно быть: https://unix.stackexchange.com/questions/179481/siginfo-on-gnu-linux-arch-lin...

В линуксе нету ни SIGINFO, ни ядерного хоткея к нему, он есть в BSD. А в линуксовый dd прикостылили USR1 вместо него, его можно с помощью kill послать.

По факту все потоки - двунаправленные пайпы, поэтому можно читать из stdout и писать в stdin. Но стандартом это не гарантируется. А тут гарантируется ради какого-то уродского легаси.