Не сломалось — не чини. Очередное свидетельство неадекватности многих линукс-админов.

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

Кто же мешает сделать легкую сериализацию пакетов из struct в pipe на C/C++ ? С какой-нибудь сигнатурой начала потока подобного объектного пайпа.

Какую сериализацию, какой struct, какая сигнатура, какие потоки ?

Одна прога читает stdin, вторая прога пишет в stdout. Всё, ты можешь эти проги друг к другу коннектить, а их результат передавать третьей проге. При чем одна может быть написана на С, вторая на PHP, третья на шелле. Более того, результат, высранный третьей прогой с моего примера, ты можешь > /dev/ttyUSB0, а на той стороне, например на Raspberry PI, сделать cat /dev/ttyS0 и увидеть результат.

Кто же мешает

Чтобы сделать - мало чтоб ничего не мешало. Надо еще, чтобы было нужно. Но оно не нужно.

Какую сериализацию, какой struct, какая сигнатура, какие потоки ?

Читай выше.

Одна прога читает stdin, вторая прога пишет в stdout. Всё, ты можешь эти проги друг к другу коннектить, а их результат передавать третьей проге.

А я не об этом писал? Вопрос был в возможности добавления специфического объектного протокола обмена, не ломая существующий.

При чем одна может быть написана на С, вторая на PHP, третья на шелле.

Причем тут язык программирования?

Более того, результат, высранный третьей прогой с моего примера, ты можешь > /dev/ttyUSB0, а на той стороне, например на Raspberry PI, сделать cat /dev/ttyS0 и увидеть результат.

И чо?

Чтобы сделать - мало чтоб ничего не мешало. Надо еще, чтобы было нужно. Но оно не нужно.

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

А я не об этом писал? Вопрос был в возможности добавления специфического объектного протокола обмена, не ломая существующий.

Шо, опять ? D-bus к твоим услугам.

Причем тут язык программирования?

При том, что «специфического объектного протокола обмена» потребует изменения логики всех существующих программ и соответственно языков. Если же ты сможешь сделать новое через старое, это будет означать что старое вполне себе может работать и без нового.

И чо?

И то шо никому и в хер не впало делать это все через какие-то объектные протоколы.

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

Ну, в мире бывают прецеденты, когда говно становится мейнстримом, но это говно должно быть авторства Потеринга.

При том, что «специфического объектного протокола обмена» потребует изменения логики всех существующих программ

Зачем всех программ? Разве недостаточно нескольких экспериментальных для начала, включая shell?

и соответственно языков.

языков то зачем?

Если же ты сможешь сделать новое через старое, это будет означать что старое вполне себе может работать и без нового.

Не вижу логической связи. Новое предлагалось как расширение старого.

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

Шо, опять ? D-bus к твоим услугам.

Причем тут D-bus, речь шла о том, чтобы задействовать существующую систему и синтаксис pipe и редиректа потоков.

Ну что за детский сад? Ты ещё в машинные коды загляни.

google://shell+prompt+generator

например https://scriptim.github.io/bash-prompt-generator/

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

Скажите, а вы осознаете, что вам придется не только вставить свою «прокладку» в реализацию пайпа в каком-то конкретном shell-е, но еще и добавить средства конфигурации соответствующего shell-а, чтобы как-то явно указывать все программы, которые способны поддерживать новый функционал? И как вы всё это представляете в целом - начиная от развёртывания дистрибутива Linux и кончая установкой нового пакета с программой, поддерживающей «новомодный» пайп?

И как всё это будет сочетаться с использованием других shell-ов?

Скажите, а вы осознаете, что вам придется не только вставить свою «прокладку» в реализацию пайпа в каком-то конкретном shell-е, но еще и добавить средства конфигурации соответствующего shell-а, чтобы как-то явно указывать все программы, которые способны поддерживать новый функционал?

Экспериментально сначала на небольшом подмножестве программ.

Можно конкретный пример несовместимости?

И как вы всё это представляете в целом - начиная от развёртывания дистрибутива Linux и кончая установкой нового пакета с программой, поддерживающей «новомодный» пайп?

Используя все старое ессно. Как устанавливают GUIX в chroot или контейнер обычного дистра?

И как всё это будет сочетаться с использованием других shell-ов?

Первое время никак вероятно, я предлагал экспериментально для одного шела, аналогично PowerShell.

PS: я НЕ являюсь системным программистом, но мне все же интересно.

Экспериментально сначала на небольшом подмножестве программ. Можно конкретный пример несовместимости?

Абсолютно непонятен смысл такого «узкого» эксперимента.
Насколько я понимаю, вы собираетесь расширить язык shell-а дополнительными конструкциями по типу PowerShell. Ну так вы тогда внутри shell-а должны программно контролировать, к каким программам можно применять эти конструкции, и выдавать «отлуп» пользователю shell-а, если он попытается «скрестить ежа с ужом» )

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

я НЕ являюсь системным программистом, но мне все же интересно

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

Абсолютно непонятен смысл такого «узкого» эксперимента. Насколько я понимаю, вы собираетесь расширить язык shell-а дополнительными конструкциями по типу PowerShell.

Лично я ничего не собираюсь реализовывать. Я просто предложил идею, не более того. И не столько по расширению языка shell, сколько по возможности передавать объекты через pipe со встроенной в shell поддержкой и парсингом такого.

Ну так вы тогда внутри shell-а должны программно контролировать, к каким программам можно применять эти конструкции, и выдавать «отлуп» пользователю shell-а, если он попытается «скрестить ежа с ужом» )

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

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

Надо ведь, чтобы и в скриптах удобно было с этим работать?

я НЕ являюсь системным программистом, но мне все же интересно
Ну вы тогда гляньте для начала полную документацию по конфигурации того продукта, который вас вдохновил.

PowerShell? Какая связь между его докой и системным программированием?

… Я просто предложил идею … по возможности передавать объекты через pipe со встроенной в shell поддержкой и парсингом такого.

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

Почему должен? Никто ничего не должен. Это просто эксперимент …

Кому нужен такой программный эксперимент? - НИКОМУ. В нём нет смысла. Смысл есть только в предварительном оформлении вашей идеи в виде дополнения к документации выбранного вами shell-а. Ну чтобы люди могли почитать и понять, предлагается ли что-то реальное и полезное или просто смутные идеи и фантазии.

Кому нужен такой программный эксперимент? - НИКОМУ. В нём нет смысла. Смысл есть только в предварительном оформлении вашей идеи в виде дополнения к документации выбранного вами shell-а. Ну чтобы люди могли почитать и понять, предлагается ли что-то реальное и полезное или просто смутные идеи и фантазии.

Что-то я не пойму, тут на форуме каждый второй по просьбе vinvlad готовит ему бесплатные тех. задания с доками в придачу? Даром, как известно, за амбаром :) (c) Русское радио, ничего личного.

А с чего вы решили, что кто-то будет спонсировать неизвестно что и неизвестно кого?) Это какие-то детские иллюзии…

Либо реализуйте своими силами что-то конкретное не требуя «спонсорства», либо оформляйте идею должным образом вместо пустого, абсолютно бессмысленного трепа - хотя бы для себя. Именно по этой причине тот же самый подход к делу был предложен еще одному фантазёру )

А с чего вы решили, что кто-то будет спонсировать неизвестно что и неизвестно кого?) Это какие-то детские иллюзии…

Где я решил, что кто-то будет спонсировать?

Либо реализуйте своими силами что-то конкретное не требуя «спонсорства»,

Ога, щаз. Мне эта тема для реализации мной самим вообще неинтересна, от слова совсем.

Я не понимаю, откуда у вас взялась взаимосвязть между «что-то предлагать и что-то делать самому»?

Ну предложил, потому что так захотелось.

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

У философии vinvlad есть уже и другие поклонники:

Пытаюсь грызть bash, зубы крошатся (комментарий)

Где я решил, что кто-то будет спонсировать?

Вам же anc предлагал - «Начинайте.»
А вы ему в ответ - «Спонсируйте :) …»
:)

Я не понимаю, откуда у вас взялась взаимосвязть между «что-то предлагать и что-то делать самому»?

Когда предлагают откровенный бред - это лучший способ вернуть человека в реальность: заставить его сделать что-то конкретное в реальном мире, касающееся его «грёз»

А вы ему в ответ - «Спонсируйте :) …»

Вы внимательно читали, что я предлагал спонсировать?

заставить его сделать что-то конкретное в реальном мире, касающееся его «грёз»

Заставить? Грёзы IMHO у вас , LOL

Вы постоянно путаетесь в терминологии, например:

Заставить и предложить

PowerShell в контексте системного программирования

и т.п.

Постоянно даете свои ненужные советы, чем мне заниматься и т.п.

Вы задали вопросы - я ответил. Ничего личного…

Вы внимательно читали, что я предлагал спонсировать?

Конечно. Но ровно с такой же «мотивацией» вы ответили и мне.

… PowerShell в контексте системного программирования

Системный программист - это программист, обладающий определенной культурой мышления и не занимающийся пустым фантазированием. Я просто попытался направить ход вашей мысли в более практичное и полезное русло - чтобы вы почитав доку поимели более чёткое представление о том, что реально потребуется сделать, чтобы воплотить вашу смутную «идею» в жизнь. Может тогда и идея отпала бы автоматом. Только и всего.

Конечно. Но ровно с такой же «мотивацией» вы ответили и мне.

А что в этом удивительного?

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

1) Я не системный программист 2) Культура мышления есть не только у системных программистов 3) Фантазирование в каком смысле пустое ?

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

А я не читал?

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

Люди… птицы… полеты…

Люди… птицы… полеты…

Фантастический Daedalus :)

Надо что-то вроде bash.ini где прописано BackGroundColor=black;

Не надо, понимаешь? В этом и прелесть, что не надо. Когда придумывали esc-последовательности, ещё цветных терминалов не было даже в проекте, а нынешние эмуляторы терминалов посреди икс-винового великолепия попросту никто представить себе не мог, не было таких ясновидящих (ясновидящих, собственно, и сейчас нет). Когда в интерпретатор Shell’а вставляли переменную PS1, этот интерпретатор работал в основном на таких консолях, где отображающим устройством был принтер, какие там ещё нафиг цвета. Ни те, ни другие «изобретатели» не предполагали, что через эн десятков лет (в первом случае больше 60, во втором поскромнее, всего-то 40 с небольшим) кому-то понадобится приглашение шелла покрасить разными цветами, как несчастного попугая с рисунка дошкольника. Ну вот вообще не предполагали, совсем, и не могли предположить, не было самой возможности сделать такое предположение.

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

Это и есть, собственно, здоровый консерватизм, на котором держатся остатки здравого смысла (а с ними – остатки полезности) в мировом IT. А все, кто пропихивает что-то новое просто ради того, чтобы оно было новое, именуемые в просторечии ньюфагами, тянут IT в деградацию, и у них это прекрасно получается, увы.

разжигает межоперационную рознь?

А чего её разжигать, она и так пылает неугасимым пламенем вот уже лет сорок. Да, виндузятников здесь многие терпеть не могут, я вот тоже не люблю, нам это что теперь, скрывать? Фигушки, мы тут на своей территории, а чего вы сюда постоянно припираетесь – ну, спросите друг у дружки, что ли, ибо нам сие непонятно.

Но они молчат. И вовсе не потому что они такие забитые и боятся. Нет, они молчат потому что их, в общем и целом, всё устраивает.

Хорошая фраза, очень актуальная и ко многому подходит, но причем тут админы?

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

Не сломалось — не чини. Очередное свидетельство неадекватности многих линукс-админов. (комментарий)

Использование некоторых инструментов разработки от Microsoft в 2022 году, вовсе не значит быть ценителем Windows.

вовсе не значит быть ценителем Windows

Если учесть, что речь идёт о PowerShell, то, по-видимому, значит быть ньюфагом. Я затрудняюсь сказать, что хуже.

Если учесть, что речь идёт о PowerShell,

https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powe...

Ну и чо? Я знаю, что ЭТО можно взгромоздить на линуксе. Вопиющая бессмысленность этого действия – вопрос второй, но тоже важный. Единственное «достоинство» PS в том, что он «типа новое слово в технологиях», больше, как тут уже говорилось, никаких достоинств нет; следовательно, это и есть то самое ньюфажство.

Самое печальное, что ньюфаги, по-видимому, никогда не кончатся. Даже виндузятники рано или поздно кончатся, но эти – никогда.

Его наработки удобно дергать из скриптов на C#, собственно для меня на этом все его преимущества заканчиваются.

На этой планете вообще дофига мест

Между прочим, есть ведь и места за пределами этой планеты. Ну, допустим, марсоходами управляют совсем специфическими средствами, на тех задержках традиционная командная строка в принципе не может существовать, даже если за консолью будет сидеть настоящий просветлённый дзен-мастер. А вот какой-нибудь геостационар, да если ещё потребуется спутник «по ту сторону шарика» с ретрансляцией через другие геостационарные – секунд пять задержки набежит без вариантов, в реальности скорее больше. А уж если Луна, так и вообще.

ты же вроде уходил? Но с возвращением.

дергать из скриптов на C#

Вот прямо просятся сразу три риторических вопроса: зачем в линуксе шарп, зачем на шарпе скрипты и зачем шарп вообще.

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

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

ценность стандарта как раз в том что он не меняется и стабилен

Ну я 14 лет дефолт не юзаю... Правда просто таскаю за собой свои конфиги которые лет 8 назад были написаны.

Вот уж что-то, а стандарты (если это именно стандарты, формально кем-то там принятые и одобренные, а не спецификации, возникшие ad hoc и которые все используют просто из-за их удобства) – так вот, стандарты меняются то и дело без каких бы то ни было причин и обоснований, просто потому что кому-то в комитете пришла в голову очередная дебильная идейка, а остальному комитету было лень возражать.

ты же вроде уходил? Но с возвращением.

Спасибо, но тот мухожук был 1 Апреля. :)

Вот прямо просятся сразу три риторических вопроса: зачем в линуксе шарп,

В Линуксе не столько шарп, сколько наконец-то возможность нормально нативно запускать сборки .NET

зачем на шарпе скрипты и зачем шарп вообще.

Один из самых лучших и удобных языков программирования после VisualBasic.NET

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

Причем тут игрушки? Unity - это просто одна из небольших областей применений C#.

Не надо, понимаешь?

Конечно понимаю, что bash.ini не нужен, потому что bash уже не спасти. Его надо выкинуть целиком.

Это плохие, негодные стандарты. Особенно когда ломают обратную совместимость. Понятно что у условного c++ с развитием языка стандарт меняется. Но если меняется стандарт у какого-нибудь Active Directory без введения новых киллер фич/фиксов критических багов, да так что ломается обратная совместимость, то уже вопросы возникают к такому стандарту. А если ломают стандарты вроде WebDAV, то это уже очень большие вопросы к ломающим.

Выдержка из моего ~/.zshrc

### PROMPT
autoload -U colors
colors

NEWLINE=$'\n'

function git_branch() {
    [ -d .git ] && echo -n "⎇ " && git rev-parse --abbrev-ref HEAD 2>/dev/null
}

setopt PROMPT_SUBST

PROMPT='[$fg_bold[green]%n@%m$reset_color $fg_bold[blue]%~$reset_color] $fg[green]$(git_branch)$reset_color${NEWLINE}\$ '

Вот так выглядит https://imgur.com/a/KuIqwk3

export PS1="\e[0;31m[\u@\h \W]$ \e[m "

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

export PS1="\[\e[0;31m][\u@\h \W]\$ \[\e[m]"

потому что bash уже не спасти. Его надо выкинуть целиком.

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

Это плохие, негодные стандарты.

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

Тот же Си++ не развивается, он деградирует.

Ещё раз, стандарт не меняется. Стандарт выходит новый.

Стандарт выходит новый.

Это абсолютно неважно, понимаешь? Просто вот есть бумажка, на ней написано «стандарт». Всё. Все, кто к этому причастен – моральные уроды и международные террористы.

Ибо ESC последовательности не для этого придумали, а то что ими можно Шелл разукрасить - сайд эффект этой фичи.

то есть ты говоришь, что способа без костылей нет, но обвиняешь ТС в неграмотности?))

Совсем чумной? Какие обвинения?😄 Перечитай комментарий ещё раз, только внимательно.

Причем тут игрушки? Unity - это просто одна из небольших областей применений C#.

Новички загораются C# благодаря Unity. Источник: я так когда-то загорелся