Всякие архиваторы тоже сцпляются через bash, значит ли это, что они через пайпу гонят поток сжатых данных?

Неужели в этих ваших юниксвеях за 40 лет ничего лучше нетипизированных синхронных текстовых уникастных потоков для реализации модульности не придумали?

можно и бинарные данные гонять, что мешает.

Что вообще есть этот bash?

внезапно, интерпретатор команд.

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

1. Можно передавать элементы массива, и в качестве разделителя использовать '\0'.

2. А как же сигналы, аргументы командной строки? Дёргать DBUS из командной сроки?

Как только надоест дрочить и потрошить строки, можно пересесть на python. Или вообще на Perl6.

Они гоняют байты. А о том, что это сжатые данные, знаешь только ты.

Неужели он только пайпами и рулит + подсветка текста

Да, только это
Ещё бикать может

есть ещё fifo

такая тема для talks, там бы кто-то рассказал как через пайпы гонять биткоины и б/у-шные ПЭТбутылки в утилизацию.

только пайпами и рулит + подсветка текста с еще чем-нибудь тривиальным опционально?

И тут я понял, что это вброс.

dbus

1. Можно передавать элементы массива, и в качестве разделителя использовать '\0'.

Получается одна строка = одно сообщение? Раз разграничителем является конец строки, то значит ли это, что будет считываться на втором конце столько же раз, сколько и при записи каждого элемента построчно? Есть ли профит в отсылке одной строкой? А двумерные массивы лучше отсылать парно тогда, не так ли?

Скоро грянуть kdbus должен, может лучше на него завязать отсылку массива? Отправляем массив, получаем массив - никаких лишних преобразований, но окупится ли выигранное время по сравнению с тормознутостью самой прослойки?

ты серьезно, или набрасываешь?

Получается одна строка = одно сообщение?

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

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

«считываться» оно будет постоянно побайтно.

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

идея

ты серьезно, или набрасываешь?

Все с чего-то начинали свой путь, пока у меня очень много вопросов. Можно ли каким-нибудь образом организовать так архитектуру программы, чтобы ее компоненты были предельно максимально независимыми друг от друга, даже гуй. Пайпы получается производительны, вот появилась следующая идея: всё добро стартует из баша (он 3.6МБ в памяти висит - не обеднеем думаю), в начале создается именованный поток: если в нем последний символ 0 - весь паровоз ставим на паузу. Дальше по пайпам бегут 3 программы, четвертая - гуй обертка с открытым stdin для вывода результата в графический интерфейс. При нажатии на кнопку (в 4-ой программе) отправляется 0 в заранее заданный пайп, отвечающий за приостановку паровоза. Так, это вариант для извращенцев. Для обычных смертных в настройках гуй обертки можно будет самому создать цепочку пайпа, в итоге каждый компонент будет удаляем и заменяем. Смысл данной наркомании в унификации и при этом модульности написанных компонентов - довольны красноглазики, прошаренные и домохозяйки. Как можно развить эту идею?

Забей уже на пайпы, что ты к ним привязался, они не для этого делались. Еще и баш зачем-то приплетаешь, лол. Шагни уже в 21 век, используй zeromq.

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

Получается одна строка = одно сообщение?

Да. Одна строка, которая заканчивается \0 = один элемент. Bash может это сделать за тебя.

Скоро грянуть kdbus должен, может лучше на него завязать отсылку массива?

Неужели он только пайпами и рулит + подсветка текста

Уроки выучи сначала.

Немного странные у тебя заявления, pipe - передача потоком. Весь Интернет на этом построен. Практически всегда программы читают из файла именно потоками. Чего не хватает?

Если тебе нужно передать несколько полей, как, например, массив - используй соотв. формат. Самый простой - придумай разделитель и разделяй им записи, благо read позволяет легко это считывать. Более сложный - json, xml. Но это для больших вещей. В bash хватит разделителя.

Альтернатива потокам - только random access (общая память и все такое). Но именно такое нужно очень редко.

Bash только пайпы подерживает как средство общения между программами?

Что значит средства общения?

Есть перенаправление ввода/вывода, есть именованные каналы, есть чтение.запись из/в файлы. Я бы это к одному и тому же относил. Это обмен данными. Еще из общения - можно обмениваться сигналами - trap в помощь. Еще есть всякие dbus, но, если тебе это нужно, скорее всего тебе нужен не bash.

Что вообще есть этот bash?

Коммандная оболочка. Интерпретатор команд, скриптовый язык с прицелом на то, чтобы быть командной оболочкой ОС; и в данном направлении - один из лучших.

Короче, поставь четко задачу, там будет видно какой способ лучший. Пока что на абстракциях «передать массив» - разделитель и в pipe, с той стороны читать с помощью read.

dbus

1. Именованный пайп взаимодействиует через узел, вот этих узлов я могу получается создать около 20 штук на программу и не потерять производительность при их использовании?
2. Что будет, если 2 внешние программы будут одновременно писать в именованный пайп?
3. Лучше создать несколько именованных пайпов для получения разных типов данных (массив и число) или лучше один пайп, но перед отправкой информации отправить некий ключ-индификатор?

вот этих узлов я могу получается создать около 20 штук на программу

Да

и не потерять производительность при их использовании?

Теория: не думаю что будет какая-то потеря производительности.

Практика: если у тебя задача, которая потребует большого количества ресурсов компьютера именно на операции скрипте, то, скорее всего, bash - неправильный выбор.

2. Что будет, если 2 внешние программы будут одновременно писать в именованный пайп?

Запусти две программы выводить что-то на экран. Или одну и параллельно печатай.

3. Лучше создать несколько именованных пайпов

Лучше использовать перенаправление ввода/вывода. Я немало написал в своей жизни bash скриптов разной сложности, и ни разу мне не понадобилось использовать именованные каналы.

для получения разных типов данных (массив и число)

Лучше всегда использовать строку. Если массив - разделитель.

или лучше один пайп, но перед отправкой информации отправить некий ключ-индификатор?

Теория: я бы сделал «идентификатором», как это сделано в JSON. Есть даже jsawk, но по-моему самому написать будет быстрее и легче. Если нужна древовидная структура - xml; xmlstarlet в помощь.

Практика: Если одна программа что-то отправляет, что другая обычно знает что именно она принимает. Так что перечня значений разделенных табулятором или чем-то еще обычно выше крыши.

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

Приведи практическую задачу, там можно будет говорить что-то конкретное.

Да так можно вообще фильмы гонять, разве нет?

можно, я разрешаю.

Bash только пайпы подерживает как средство общения между программами? Что вообще есть этот bash? Неужели он только пайпами и рулит + подсветка текста с еще чем-нибудь тривиальным опционально?

подсветкой рулит терминал, а пайпами ядро. Пайпы тоже файлы.

Неужели в этих ваших юниксвеях за 40 лет ничего лучше нетипизированных синхронных текстовых уникастных потоков для реализации модульности не придумали?

1. они не текстовые.

2. говношелл не нужен.

Все с чего-то начинали свой путь, пока у меня очень много вопросов.

начнём с того, что bash это не ЯП общего назначения, а такой «клей», которым админы могут склеивать несколько команд.

Иди учить нормальный ЯП, питон например. Или сишку.