История изменений

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Хорошо, что ты в целом понимаешь, что нужно пытаться ввести собеседников в контекст и пытаешься (хоть и не очень получается) сконкретизировать свой запрос.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать и по умолчанию не буфферизуется (об этом позже)

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы. Ещё точнее, файловые дескрипторы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, fileno(stdout)) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout. fileno(stdout) это чтобы получить сам файловый дескриптор.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с общим пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.

P.s. Когда диды завещали «всё есть файл», они, на самом деле, имели в виду, что всё есть реализация абстрактного интерфейса «файл». То есть всё унифицированео и поддерживает файловые операции. Изнутри это далеко не обязательно файл. Но ты можешь с ним работать как с файлом и полноправно делать вид, что кроме файла это ничем другим быть не может.

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Хорошо, что ты в целом понимаешь, что нужно пытаться ввести собеседников в контекст и пытаешься (хоть и не очень получается) сконкретизировать свой запрос.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать и по умолчанию не буфферизуется (об этом позже)

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы. Ещё точнее, файловые дескрипторы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, fileno(stdout)) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout. fileno(stdout) это чтобы получить сам файловый дескриптор.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с общим пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Хорошо, что ты в целом понимаешь, что нужно пытаться ввести собеседников в контекст и пытаешься (хоть и не очень получается) сконкретизировать свой запрос.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать и по умолчанию не буфферизуется (об этом позже)

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы. Ещё точнее, файловые дескрипторы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, fileno(stdout)) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout. fileno(stdout) это чтобы получить сам файловый дескриптор.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Хорошо, что ты в целом понимаешь, что нужно пытаться ввести собеседников в контекст и пытаешься (хоть и не очень получается) сконкретизировать свой запрос.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать и по умолчанию не буфферизуется (об этом позже)

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы. Ещё точнее, файловые дескрипторы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, stdout) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Хорошо, что ты в целом понимаешь, что нужно пытаться ввести собеседников в контекст и пытаешься (хоть и не очень получается) сконкретизировать свой запрос.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать и по умолчанию не буфферизуется (об этом позже)

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, stdout) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Хорошо, что ты в целом понимаешь, что нужно пытаться ввести собеседников в контекст и пытаешься (хоть и не очень получается) сконкретизировать свой запрос.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать.

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, stdout) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.

ставят знак клоуна

Не обращай внимание. Думаю, дело в том, что твоё сообщение ну очень не концентрированное и длинное. Пока читаешь к концу, забываешь, что было в начале, и в чём, собственно, сам вопрос. Поработай чуть-чуть над тем, как форумлируешь вопросы. Так и тебе будет легче найти помощь, и людям легче тебе помочь.

а просто унижают, надоело

Кто-то отвечает на твой вопрос, кто-то выражает мнение. Кто-то первое или второе делает чуть-чуть токсично. Это интернет, ничего не поделаешь, так везде, особенно, если собеседникам кажется, что ты слишком сильно тупишь. Но ты движешься в правильном направлении, так что сильно не волнуйся.

Что такое stdin/stdout?

С точки зрения процесса, просто файлы. Один только для чтения, другой только для записи. Есть ещё stderr, который как stdout, но чтобы ошибки писать.

Обычно это просто ввод и вывод консольки. Туда юзер тык-тык, а сюда юзер зырк-зырк. Но это не правило, а просто частный случай. Опять же, это просто файлы.

Что такое файл?

Файл это абстракция. Файл может быть на диске, а может быть и в памяти. А может вообще никакого файла не быть, но это структура ведёт себя ну прям как файл.

С этого момента и далее воспринимай это слово так и дальше.

Что такое pipe?

Вот у тебя есть процесс А и процесс Б. Они невероятно хотят общаться.

И есть ещё такая кишка, пайп, в которую можно засунуть текст (или поток байт) на вход и получить на выходе.

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

Pipe расшифровывается как pipeline, то есть конвейерная лента.

А что такое оператор пайпа в bash?

Ничего он особенного не делает, просто берёт stdout одного процесса и пишет в stdin другого.

apt search python | grep pip — значит ты вызываешь апт и просишь найти пакеты с именем пайтон. И выводит это, как правило, в консоль. Но на самом деле, этот stdout оказывается в stdin программы греп и она начинает с этими данными тоже что-то своё делать.

А если ты просто вызовешь grep pip, сможешь сам писать ему какие-то строки. В ответ он выведет только те, в которых есть нужная подстрока.

Менее наглядный, но более точный ответ уже написали тут до меня.

Просто в стандартной библиотеке rust можно читать из stdout только когда процесс завершен

Я с конкретно стандартной библиотекой не знаком, но это работает не совсем так. Тебе попался очень частный случай.

Дело в том, что запись в любой файл, в том числе в stdout может буфферизоваться. Это делается ради оптимизации.

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

Поэтому ты вроде что-то пишешь, а по факту этот вывод просто накапливается в каком-то буффере. Когда он переполняется — вывод выплёвывается сразу пачкой.

Чтобы вывести прямо и здесь и сейчас, обычно есть какой-нибудь fflush или fsync. Плюс, оно, конечно, неявно происходит при завершении работы.

Я НЕ УВЕРЕН, какие есть ограничения у стандартной библиотеки Rust. Тем более, это ещё и очень сильно зависит от вызываемой программы.

Как сделать пайп в (имя языка)?

Тут читай доки. Ссылки и какие-то примеры вроде тоже кто-то привёл.

Считаются ли пайпы IPC

Да, самый базовый.

Как сделать, чтобы когда архиватор делает вжыньк прогрессбаром и я это детектил? 🤓

В идеале никак. Такую жуть парсить зачем? Лучше возьми библиотеку-архиватор, попроси её заархивировать и проверяй напрямую. Так вкуснее и менее муторно.

Я всё равно очень хочу! Или не имею другого выбора.

В вызываемой программе создаёшь пайп. Получишь два файловых дескриптора, на одном конце у тебя чтение r, а на другом запись w.
Вызови fork, то есть создай копию процесса.
В дочернем закрой r — тыж пишешь, а не читаешь)
В дочернем сделай dup2(w, stdout) — то есть сделай так, чтобы дескриптор w склонировался и заместил собой stdout.
В дочернем закрой w — он же после этого никуда не пропал!
Вызови exeс и запусти искомую программу. Дескрипторы файлов уже подменены, а она, дура, ничего и не поймёт.

Как бэ, всё, profit. Это я на уровне системных вызовов Linux. Если хочешь стандартной библиотекой какого-либо языка, поищи доки, где-то оно должно быть.

Анонимные от именованных чем-то отличаються?

Убери мягкий знак. И лучше бы сначала погуглил, ответ в первой ссылке.

Вкратце — нет.

И то, и то один и тот же файл.

Только анонимный пайп это просто два файловых декриптора, два номера, два идентификатора.

А именованный это то же самое, но ещё и делает вид, что оно прям в натуре файл в дереве файловых систем.

Вон если у тебя одна из программ умеет принимать только файлы, а другая умеет работать только с stdin/stdout — ты можешь их объединить именованным пайпом.

Одно думает, что пишет в сонсольку, а другое думает, что читает из файла — все счастливы и никто не подозревает, что на самом деле они работают с пайпом.

А можно ли в пайп сразу и читать, и писать?

Доку читать лучше всего. Можно. Пайпы это штука без выраженного направления. Правда ты поди ещё смотри, чтобы выводы двух программ в пайп не смешались в кашу.

Хорошо, вот концентрат: Я хочу в идеале понять как это работает, но статьи про это какие-то поверхностные. Если про все методы ipc брать, то ещё поверхностнее.

Есть и норм статьи, просто надо в голове объединять информацию.

А ещё у линукса просто шикарная дока на все случаи жизни. Где-то даже есть переведеные страницы, но советую читать на английском.