сначала мы форкаемся, потом тот процесс, который получил от форка 0, понимает что он тут дитя и делает exec* будущего процесса.

а родитель получает от форка пид ребенка и радуется

я КО, да?

сам по себе fork ни какие fd не меняет

да, разумеется. Поэтому ребенок должен избавиться от родительского 0 и 2, назначить себе бывший 1 на 0 (если только мы сделали перенаправление, вроде &>1), открыть новые 1 и 2. Так?

Я могу только высказать предположение, за точностями надо в код залезть.
в случае pipe? Да, ребёнок пропишет себе свой текущий 1 в 0, а 1 переправит в /dev/stdout, а родитель наверняка перед форком создал fifo и назначил его в 1.

@Laziness_Itself а еще наша лекция будет неполной, если не сказать, что в ядре никаких вызовов "запусти мне вон ту программу" нет. Есть группа exec* (всякие execve например, go figure), которые заменяют выполняющуюся программу на нужную тебе. Поэтому, чтобы запустить внутри баша греп, ты
1. форкаешься
2. У тебя есть два баша на одном и том же месте выполнения программы, сразу после форка. Чтобы понять, ты родитель или дитя, ты смотришь возврат форка. Родитель получит пид ребенка, ребенок - 0 (ЕМНИП).
3. Процесс-ребенок выполнит ^^^ вуду с fd, потом сделает exec и превратится в ту программу, которую ты хочешь запустить. Например, в греп.

без pipe, просто вызов grep не будет вообще ни чего делать с fd

Жуть

а ты думал, просто в стиле питончика system("/bin/grep") и дело в шляпе? А вот хренушки...

Я вообще не думал😅

Так тут тоже ж самое происходит

Или хуже? Там ещё sh создаётся сначала

под капотом - да. Но с точки зрения пайтон-программиста никаких форков нет.

Ну вы развели тут лекторий

А мне так и не ответили пару дней назад как переменные прокидывать в родительский шелл

Я пропустил - разве это возможно? О_о

Нет)

Никак.