Unix-way не торт

[myst]

Мне надо смастерить следующий агрегат:
data-source₁ → filter₁ →
                                       ↘
                                           →  comparator → result
                                      ↗
data-source₂ → filter₂ →

[oort]

Что принимает на вход компаратор? Точнее -- в каком виде?

[Алексей Гринь]

Unix-way это три слова: сопли, костыли, скотч.

[myst]

Что принимает на вход компаратор? Точнее -- в каком виде?

А какая разница?

[Demetrius]

Что принимает на вход компаратор? Точнее -- в каком виде?

Логично предположить, что текстовые строки. Потому что в unix-way только они и предусмотрены. 

[myst]

Unix-way это три слова: сопли, костыли, скотч.

Текущая реализ помойка просто бесит. За n-цтать лет никакого порядка так и не навели. Позорники!

[oort]

Цитата: oort от Вчера в 18:20

Что принимает на вход компаратор? Точнее -- в каком виде?

А какая разница?

Если он еще не написан -- его можно написать так, чтобы он удовлетворял описанным условиям. Если он уже написан не в unix way, то кто ж ему виноват.

[myst]

Дело какбэ вообще не в типе данных.

[Demetrius]

Если он еще не написан -- его можно написать так, чтобы он удовлетворял описанным условиям. Если он уже написан не в unix way, то кто ж ему виноват.

Так вопрос же и был — как это нормально написать в unix-way, если stdin только один?

[myst]

Так вопрос же и был — как это нормально написать в unix-way, если stdin только один?

Именно. Нужны нелинейные конвейеры. Собственно средства для этого есть, но за 30 лет никто так и не почесался сделать.

[oort]

А зачем через stdin? Насколько я понимаю, unix way состоит в обработке данных по частям, а не в том, что эти данные обязательно должны передаваться через пайп, и никак иначе.

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

[myst]

А зачем через stdin? Насколько я понимаю, unix way состоит в обработке данных по частям, а не в том, что эти данные обязательно должны передаваться через пайп, и никак иначе.

У вас какой-то другой unix way.

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

А вот с этого момента поподробнее, пожалуйста, с sello'вскими примерами и coreutils.

[oort]

Код Выделить Развернуть

mkfifo /tmp/fifo{1,2}
prog1 | filter1 > /tmp/fifo1 &
prog2 | filter2 > /tmp/fifo2 &
comparator /tmp/fifo{1,2}
Или я неправильно понял постановку задачи?

[myst]

Это ниинтересна. Пространство имён файловой системы всё равно засирается.

[oort]

Ну, все-таки в любой юникс-вейной ОС есть /tmp.

[myst]

Ну, все-таки в любой юникс-вейной ОС есть /tmp.

Это ничего не меняет. Костыльные костыли. А разгадка — в безблагодатности одномерного конвейера.

[Anjiko]

Так смысл поста топикстартера в решении задачи, или все же обгадить unix-way? Не нравится, не используй. А то начинается, "аа, тут не так, аа все это фигня"))

[myst]

Ну давайте уже Ваши решения этой задачи без побочных эффектов.

[Python]

Это ниинтересна. Пространство имён файловой системы всё равно засирается.

Достаточно сделать имена  уникальными (на случай, если наш скрипт вызывается одновременно из нескольких процессов). Представим себе костыль (kostyl), который генерирует уникальное имя, создает фифо с этим именем, выдает это имя через стандартный вывод, а стандартный ввод копирует в фифо. Тогда с его использованием команда будет выглядеть следующим образом:

comparator `prog1|filter1|kostyl` `prog2|filter2|kostyl`

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

[myst]

Достаточно сделать имена  уникальными (на случай, если наш скрипт вызывается одновременно из нескольких процессов). Представим себе костыль (kostyl), который генерирует уникальное имя, создает фифо с этим именем, выдает это имя через стандартный вывод, а стандартный ввод копирует в фифо.

Чё его представлять, он mktemp называется.
Убирать в пространстве имён будет дядя?
Я уже заколебался создавать временные файлы и удалять их потом.

[Python]

Убирать в пространстве имён будет дядя?

В случае Windows-way, очень часто убирает именно дядя пользователь. Если имя в папке temp, ни с чем не пересекается, то кому оно мешает?

[myst]

В случае Windows-way, очень часто убирает именно дядя пользователь.

Что такое Windows-way?

[myst]

comparator `prog1|filter1|kostyl` `prog2|filter2|kostyl`

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

Как это вообще будет работать? kostyl заблокируется на пайпе, и ага.

[Python]

Как это вообще будет работать? kostyl заблокируется на пайпе, и ага.

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

Windows-way — это пять слов: сопли, костыли, скотч, красивая обертка

[myst]

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

После того как всё скопирует.

Хочется нелинейности и безо всяких побочных эффектов. Накидал фильтров, сепараторов, смесителей etc. — и щастье.