Comments 88
До json популярным был формат xml. Однако сообщество не торопилось принимать на вооружение xml для передачи данных через потоки ввода/вывода. Может и сейчас не стоит торопиться нагружать код всех утилит генераторами и парсерами json?
Вот, например, посмотрите на более простую и удобную для разбора форму вывода утилиты lsblk, где вы можете выводить любые, выбранные вами, значения (с поясняющим заголовком или без такового) в одну строку через пробелы.
lsblk(1).
Что json, что xml, оба так себе подходят для потоковой передачи. Точнее совсем никак не подходят. Хотя костыли есть.
Конечно, должно быть все в Yaml
Далеко не всегда имеется смысл в именно потоковой передаче.
Опять же, ничто не мешает передавать ответ не одним json-ом, а несколькими, каждый в отдельной строке.
Ну да, не всегда. Но чаще чем кажется. И бенефиты дает дополнительные.
Далеко не всегда имеется смысл в именно потоковой передаче.
понимаете в чём проблема, сегодня вы делаете некий формат, который должен заменить текст. завтра вам придётся вдруг передать от процесса к процессу больше информации, чем помещается в ОП, а утилиты будут уже использовать этот формат.
у grep/sed/awk и прочих олдскульных утилит нет проблем с обработкой гигантских потоков данных, а с xml/json будут.
Вы в курсе sax xml? Именно, для потоков и никаких проблем
да, в курсе. но ведь нет гарантий, что он всеми будет использоваться.
P. S. я не пытаюсь сказать, что plain text — наше всё и пытающиеся придумать что-то другое должны быть сожжены за ересь. я лишь говорю, что надо хорошенько подумать. картинку про новый стандарт все помнят, думаю.
А вот помогите дураку, почему нельзя передавать какой-нибудь https://en.wikipedia.org/wiki/Media_type а потом blob этого типа? Есть уже наверное такой мета-стандарт передачи ... в интернете используется ) Потоковая передача - кушаем blob пока не встретится следующий media type заголовок. Ну это я от фонаря сморозил, наверняка много-более-ученые умы об этом уже чесались как-то особо правильно ...
Если нужен поток объектов JSON то просто закрываешь один и открываешь другой. В том же Go json.Decoder парсит такой поток из коробки.
А если нужно передать просто большой объект то тут уже да, только атомарно.
Но те же проблемы и с обычным текстом, когда для парсинга необходим контекст из предыдущих строк.
Однако сообщество не торопилось принимать на вооружение xml для передачи данных через потоки ввода/вывода.
Ну и плохо. Добавление нового не означает ведь отказ от старого. Никто же отбирает старый добрый плоский текст, и в этом смысле для меня непонятна инерция сообщества. «Не торопились», это скорее всего вопрос мотивации, а не целесообразности. А тут вскрывается более глубокая проблема юникса — отсутствие руководящей политики партии и множественность конкурирующих решений, которые порой придумываются абы только не так как у других.
"Не торопились" но двигались. Вот вам пример: Subversion предусматриала вывод в XML формате. Однако в массах XML-вывод остался не востребован.
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Яблоки</h:td>
<h:td>Бананы</h:td>
</h:tr>
</h:table>
<f:table xmlns:f="http://www.w3schools.com/furniture">
<f:name>Африканский кофейный столик</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
{
"root": {
"h:table": {
"-xmlns:h": "http://www.w3.org/TR/html4/",
"h:tr": {
"h:td": [
"Яблоки",
"Бананы"
]
}
},
"f:table": {
"-xmlns:f": "http://www.w3schools.com/furniture",
"f:name": "Африканский кофейный столик",
"f:width": "80",
"f:length": "120"
}
},
}
Автоматизированная тулза кушающая произвольный XML вам такой JSON не выдаст. А даже если вы и навставляете костылей, чтобы генерировалось именно это - обрабатывать такой JSON будет настоящим адом, ибо малейшее изменение XML будет серьёзно менять структуру JSON.
https://www.utilities-online.info/xmltojson
ибо малейшее изменение XML будет серьёзно менять структуру JSON
покажите пример, как малейшее изменение в XML приводит к серьезным изменениям в JSON
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Яблоки</h:td>
<h:td>Бананы</h:td>
</h:tr>
</h:table>{
"h:table": {
"-xmlns:h": "http://www.w3.org/TR/html4/",
"h:tr": {
"h:td": [
"Яблоки",
"Бананы"
]
}
},
"#omit-xml-declaration": "yes"
}<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Яблоки</h:td>
</h:tr>
</h:table>{
"h:table": {
"-xmlns:h": "http://www.w3.org/TR/html4/",
"h:tr": {
"h:td": "Яблоки"
}
},
"#omit-xml-declaration": "yes"
}<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Яблоки<br/></h:td>
</h:tr>
</h:table>{
"h:table": {
"-xmlns:h": "http://www.w3.org/TR/html4/",
"h:tr": {
"h:td": {
"#text": "Яблоки",
"br": {
"-self-closing": "true"
}
}
}
},
"#omit-xml-declaration": "yes"
}А зачем, собственно, конвертировать из одного формата в другой? Программа выдала результат в XML — обрабатываете XML. Программа выдала результат в JSON — обрабатываете JSON.
XML гораздо богаче, чем JSON. Взять те же комментарии. Так что автоматически любой XML преобразовать в JSON невозможно.
Это еще не совсем XXI век. Лучше строго-типизированное двоичное представление. Отказ от многих вариантов вывода, а использовать отдельные программы для парсинга и вывода (в таблички, в джсон итп). Ой, мы изобрели power shell.
Но и это ещё не всё. Все эти инструменты командной строки остались в основном в области администрирования либо используются разработчиками под *nix. Большинство пользовательских программ — страшные монолиты. Вот если применить UNIX-way там каким-то образом, то это было бы точно на уровне XXI века.
Ну почему сразу только страшные и только монолиты? Построение программ из компонентов, которые решают каждый свою задачу, обмениваясь данными по стандартным протоколам… Ой, мы изобрели SOA? Или микросервисы? И таки да, типизированные протоколы обмена, когда компоненты обмениваются не текстом без структуры через пайпы, а типизированными сообщениями скажем через кафку — вот это, вообще говоря, и является типичным для 21 века. И как это сделать из монолита — примерно понятно. Юникс вей правда к этому за уши притягивать не имеет смысла.
Личная просьба. А давайте строго-типизированное двоичное представление будет не в XXI, а в XXII веке, чтобы я гарантированно не дожил до этого счастья.
$ ifconfig ens33 | grep inet | awk '{print $2}' | cut -d/ -f1 | head -n 1
ifconfig ens33 | awk '/inet / {print $2}'
Вот да! Тоже люблю авку, для парсинга и обработки многоколоночного вывода!
Никаких проблем ровно до тех пор, пока у вас нет пробелов среди значений.
Скорее: безопасно использовать исключительно литанские буквы и цифры. Всё остальное - хождение по минному полю.
Никаких проблем ровно до тех пор, пока у вас нет пробелов среди значений.
Попробуйте
$ echo "a b c,d e f" | awk 'BEGIN{FS=","};{print $2}'
Или
$ echo "a b c,d e f" | awk -F ',' '{print $2}'
Или Вы о чём-то другом?
Как вариант:
$ ifconfig ens33 | grep -Po 'inet \K(\d{1,3}\.){3}\d+'
Хотя с awk, конечно, элегантнее.
JSON не самый лучший выбор для этих целей. Тут я рассказывал про более подходящий формат. Вот пример оттуда:
> git log
commit
message \$mol_style: TS@3.9 compatibility
sha \b1a8f07c839604d0d34430a186246f0c1f71e628
date \2020-05-15T23:24:32+0300
author \nin-jin <jin@example.org>
commit
message \$mol_regexp: concurent parse ability
sha \be1abfa50542728dd5c156517ea31f469e7fb4d4
date \2020-05-15T23:03:30+0300
author \nin-jin <jin@example.org>
> git log | pick date message | table
\2020-05-15T23:24:32+0300 $mol_style: TS@3.9 compatibility
\2020-05-15T23:03:30+0300 $mol_regexp: concurent parse ability
Насколько имеет смысл ограничиваться консолью и текстовым форматом (пусть и в JSON)? Не имеет ли смысл пересмотреть концепцию на более глубоком уровне, допустив, что у программ могут быть не только текстовые входы и выходы?
только тот же офис в результате ушёл от бинарных форматов хранения документов.
Дело ведь не в формате, а в том, что всё связывание программ и организация потоков данных осуществляется через командную строку консоли. Когда-то у Microsoft была задумка — COM-объекты, ActiveX, встраивание одних документов и программ в другие… Но в конечном итоге оно пошло куда-то не туда, возможно технология была слишком сложной, или ей чего-то не хватало.
Но в конечном итоге оно пошло куда-то не туда, возможно технология была слишком сложной, или ей чего-то не хватало.
так про это и речь, de facto простые текстовые протоколы победили.
Впрочем, тут можно углубляться очень глубоко. Возможно, дело в текстовой клавиатуре и изначально текстовых интерфейсах пользователя. Или в изначально последовательном командном способе взаимодействия с компьютером. Или еще в чем-то.
там xml, который вы руками править точно не будете
Как раз-таки правил пару раз этот XML, чтобы зачинить баги форматирования в большом документе. И сделать это было глобально проще, чем писать парсер бинарного формата.
Мне как-то доводилось работать с xlsx документом почти мегабайтного размера, что довольно существенно тормозило, при этом казалось что данных в нём всего ничего. Заглянул внутрь файла, в xml, и оказалось, что в нём объявлены какие-то адские тысячи невидимых объектов.
Я их удалил sed'ом. Из xml.
А зачем переделывать существующее программное обеспечение, если сам автор, по его словам, уже написал инструмент для унификации вывода? Разве не будет Unix-way, так и оставить, существующее ПО делает свою работу, а программа автора заниматься унификацией вывода?
Всякие "обычные"/"стандартные" утилиты Unix/Linux предназначены в первую очередь для человека, сидящего перед терминалом. Формат JSON всем прекрасен, кроме того, что он не удобен для чтения человеком. Зачем превращать интрумент из того, для чего он предназначен, в то, для чего он не предназначен?
Если кому нужно что-то очень сложное, он должен не трубопровод строить, а написать программу на Питоне, для которой уже не будет проблемы расшифровать что угодно.
JSON вполне читаем человеком, по крайней мере он точно не хуже XML
Предлагается опционально выводить в JSON же, с флагом.
А так можно было бы и YAML, он вполне читабелен и взаимозаменяем с JSON
Если json делать по-человечески , он вполне читаем.
Если же делать, как например, внутри сэйвов Pathfinder'a, то это лютый трэшак.
Вот из этого
{"ip": "127.0.0.1",
"port": 6000,
"flags": ["a", "b", "c"]
}
фигня вопрос сделать вот это
127.0.0.1:6000 a,b,c
а наоборот — нет. Не проблема отобразить данные в удобном для человека виде. Проблема в обратном — чтобы преобразовать данные скриптом, вам надо распарсить текст в некоторое структурированное представление. И вот тут непонятно, почему бы их сразу и не отправлять в удобном для парсинга виде.
Программы — мелкие и совершенные (совершенные в прямом смысле слова, если залезть в исходники — часто последнее изменение случилось 20 лет назад).
Программист/админ не пишет программу «чуть лучше чем было», а строит «трубопровод» — скрипт где мелкие программы передают параметры друг другу. Это позволяет быстро потом разобраться другому программисту. Быстро изменить что-то из этих стандартных кирпичей.
«Написать на Питоне» часто не выйдет, просто потому что Питон не включен в стандарт Posix. Это невозможно, например, на слабых встраиваемых решениях с 8МБ памяти. А unix way это про универсальное решение для любых машин.
Также вся система представляет собой «трубопроводы» из стандартных кирпичей — наборы скриптов.
Всё это позволило системе выжить, стабилизироваться и влезть в телефоны, суперкомпьютеры, сервера и игровые приставки.
GUI не входит в стандарт POSIX. Речь идет о системном программировании. Здесь гуй не нужен и даже вреден. Исходники ядра Линукса не открывают в IDE, особенно если целевая платформа за тысячи километров с плохой связью.
Программы — мелкие и совершенныеЭто уже давно не так — почитайте статью про разрастание числа параметров в стандартных утилитах. Во многом это происходит именно из-за того, что в качестве формата взаимодействия используется неструктурированный текст.
Всё это позволило системе выжить, стабилизироваться и влезть в телефоны, суперкомпьютеры, сервера и игровые приставки.Выжить экосистеме позволил свободный подход (Bazaar vs Cathedral), но обратная его сторона — усложнение развития и взаимодействия, про которое и идет речь в статье.
А завоевать рынок позволила, скорее всего, открытость — для многих технологических компаний создавать систему полностью с нуля неподъемно дорого, основываться на решениях конкурентов небезопасно, поэтому единственным рабочим вариантом остается open source.
А завоевать рынок позволила, скорее всего, открытость — для многих технологических компаний создавать систему полностью с нуля неподъемно дорого, основываться на решениях конкурентов небезопасно, поэтому единственным рабочим вариантом остается open source.
Глупости. До появления open source юниксы вполне себе завоевывали рынок, будучи коммерческими. И технологические компании вполне себе строили свои Unix like системы с нуля.
«Написать на Питоне» часто не выйдет, просто потому что Питон не включен в стандарт Posix. Это невозможно, например, на слабых встраиваемых решениях с 8МБ памяти.
MicroPython работает даже с 16KB памяти.
Подождите, но любая программа тоже "трубопровод" из совершенных кирпичиков стандартных лексем "if", "switch" и базовых элементов стандартной библиотеки типа "Math.Cos". И за последние 20 лет наработки в области читабельности сделали огромнейший шаг вперёд. А вот в этом unix-way сложность понимая растёт буквально экспоненциально с увеличением размера скрипта.
То есть ты можешь дергать системные функции как printf либо твоя программа должна умещаться в эти 9 кБ. Память была на тороидальных трансформаторах. Дисплея также не было, все через телетайп.
Когда придумали скрипты — вышло отлично — каждый вызываемый кирпич после себя освобождает память полностью.
Вторая проблема — нет интернета, нет стековерфлоу. Документации также нет. Вся документация это man и на крайний случай исходники. В сложных монструозных проектах тяжело разбираться.
Гугл пишет свои системы сборки на питоне или java, это хорошо, я этим с удовольствием пользуюсь. Но представьте что вам нужно починить компьютер в закрытом заведении. Вы даже не знаете что за версия там. Нет интернета. В POSIX-системах это не проблема. По стандарту там есть gcc, bash, vi и man — вся документация. Этого достаточно. Интернет не нужен чтобы искать документацию на конкретные версии, все уже там, инструменты также там. Программы короткие и простые. Совершенные) Разобраться также будет не сложно.
В вашем же случае, в случае нестандарта, окажется что исходников нет, а если нет, то нет компилятора. Если компилятор есть, то нужно отдельно искать документацию и так далее.
Любой стандарт не только зло, но и добро. А POSIX это стандарт. Конечно, сейчас уже мало кто кладет в систему Фортран, который требуется по-стандарту, но представьте что сейчас в 2021 году не представит труда починить какой-то unix-сервер из 1990 года, когда вендор может уже разорился.
Так о том и речь. Что переносить философию Unix в 21 век совершенно бессмысленно. Интерпретатор питона работает даже под 98 виндой. Поставить его просто (а с практически любым пакетным менеджером - очень просто) или вообще можно принести в виде portable. И он уже давно поставляется в базе практически любого дистрибутива. То же самое касается и java.
Не, ну большинство языков программирования внезапно транслируются в Си-код, а этот код потом собирает Си-компилятор. Который также детище unix.
Питоновские библиотеки также часто написаны на Си и верхний уровень только дергает их. Сам питон тоже конечно можно пересобрать.
Мир не ограничен десктопом. Большинство выпускаемого железа это вообще не десктоп, а всякие роутеры, автомобильные компьютеры и прочее прочее. Там Питон это не то что идет в продакшн, а только для быстрого прототипирования.
С Питоном так не выйдет, потому что в стандарт не входит.
Почему? Интерпретатор Python — это же обычное приложение, которое будет работать на любой POSIX-совместимой ОС. В свою очередь, Python также предоставляет некоторый стандартный функционал.
Не, ну большинство языков программирования внезапно транслируются в Си-код, а этот код потом собирает Си-компилятор.
Мне кажется, вы немного отстали от жизни. Для компилируемых языков сейчас в тренде LLVM-бэкэнд.
Ну на linux смартфонах Nokia N9 и особенно на Nokia N900, питон очень активно использовался как для написания софта, так и для всякой околосистемщины Так что не всё так однозначно © Опять-же, если вспомнить пакетный менеджер yum...
Ну раз заговорили про 98-ю винду... Не далее как сегодня, у человека у которого в хозяйстве энное количество AIX-ов, на IBM Power... Вообщем Python там ставится отдельно и он далеко не 3.x ветки... И лежит по нестандартному пути. Поэтому ansible берёт и обламывается. Пришлось костылить, через POSIX утилиту, кстати, ansible_python_interpreter=/usr/bin/env python в инвентори. И оно работает! Но опять-же, тот-же sh есть чуть менее чем везде.
Как Вы пишите, JSON появился в 2013 году, однако я с ним работал уже в 2010.
Просто оставлю это здесь https://habr.com/ru/company/mailru/blog/314014/
У json есть фатальный недостаток - отсутствия поддержки бинарных данных.
$ lsblk --help | grep json
-J, --json использовать для вывода формат JSON
$ lsblk --version
lsblk из util-linux 2.37.2
Отлично. Теперь я могу сделать jdemon который через рест апи будет выдавать json от всех этих штук
The ip command is the future of network config commands. ifconfig has been officially deprecated for the ip suite, so while many of us are still using the old ways, it is time to put those habits to rest and move on with the world.
а далее что human is depricated?
А вот ip route, не выводящий JSON, даже с флагом -j:
> ip -V
ip utility, iproute2-5.13.0
> ip -j route
[{"dst":"default","gateway":"192.168.5.1","dev":"enp37s0","protocol":"dhcp","metric":100,"flags":[]},{"dst":"192.168.5.0/24","dev":"enp37s0","protocol":"kernel","scope":"link","prefsrc":"192.168.5.102","metric":100,"flags":[]}]
Выглядит так, как будто автор не знает о существовании powershell для Linux. В нём и JSON гонять можно и конвееры человеческие писать. Вот это, действительно, решение 21-го века!
Selinux, auditctl предельно некомфортные для работы программы. Думаю из за бинарности, нечитаемости. Они не настолько сложные, что бы быть настолько отвратительными, в прямом понимании. По любви с ними никто не имеет дела.
Инструмент хороший, спасибо.
Но почему python, а не бинарник? Это сильно ограничивает возможности использования, ведь не везде есть python.
Переносим философию Unix в 21 век