LINUX.ORG.RU
ФорумTalks

Бинаризация всея Линукса

 ,


0

0

Копипаста с опеннета:

Раздумывая над способами модернизации командной строки UNIX, Александр Ларсон (Alexander Larsson), активный разработчик GNOME и мантейнер таких проектов, как Nautilus, Gnome-vfs и Dia, предложил в своем блоге новый способ объединения команд с помощью пайпов, основная идея которого заключается в передаче через канал не простых потоков неструктурированных данных, а объектов, представленных в бинарной форме. По словам Александра, его идея может сделать командный интерфейс более гибким, но не таким переусложненным как Microsoft PowerShell.

В качестве основы для представления объектов Александр предложил использовать тип данных GVariants из библиотеки Glib, используемой также в GTK+ и GNOME. Он реализовал несколько утилит, повторяющих функциональность стандартных UNIX-команд ps, sort, head и других, которые принимают на вход и выдают на выходе объекты типа GVariants, причем в случае, если вывод осуществляется в терминал или принимающая команда не поддерживает на входе объекты, данные будут переданы в текстовой форме. Например, вывод его версии ps в терминал будет выглядеть так:

$ dps
   <{'pid': <uint32 1>, 'ppid': <uint32 0>, 'euid': <uint32 0>,  'user': <'root'>,...
   <{'pid': <uint32 2>, 'ppid': <uint32 0>, 'euid': <uint32 0>,  'user': <'root'>,...
   ...

Применив к этому выводу другие утилиты можно легко отсортировать объекты по необходимым полям и выполнить их фильтрацию на основе тех или иных полей:

$ dps | dfilter euid \< 1000 | dsort rss
   <{'pid': <uint32 1>, 'ppid': <uint32 0>, 'euid': <uint32 0>, 'user': <'root'>,
   <{'pid': <uint32 769>, 'ppid': <uint32 745>, 'euid': <uint32 0>, 'user': <'root'>,
   ...

В конце концов, можно использовать специальные утилиты для вывода данных удобочитаемом виде:

dps | dfilter euid \< 1000 | dsort rss | dhead 4 | dtable pid user rss vsize cmdline
   pid     user      rss    vsize  cmdline
     1   'root'    24408    61488 '/usr/lib/systemd/systemd'
   769   'root'    16028   108000 '/usr/bin/Xorg :0 -background none -logverbose 7 -seat seat0 -nolisten tcp vt1'
   608   'root'    15076   255312 '/usr/bin/python /usr/sbin/firewalld --nofork'
   747   'root'     8276   452604 '/usr/sbin/libvirtd'

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

Ответ на: комментарий от tailgunner

Ну как там написано: если утилита выводит список каких-то данных, а тебе надо обработать их дальше, то не надо парсить текст на выходе.

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

Zorn
()
Ответ на: комментарий от Zorn

Ну как там написано: если утилита выводит список каких-то данных, а тебе надо обработать их дальше, то не надо парсить текст на выходе.

И как это уходит с введением опции --object?

tailgunner ★★★★★
()

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

ЗЫ для тех кто считает нововведения правильными. Если не копать, то действительно не важно чем - лопатой или вилами.

chenger ★★
()
Ответ на: комментарий от x3al

Подожди. Перевод данных в относительно плейн текст и парсинг его на другой стороне — это уже не сериализация/десериализация?

Вы имеете в виду современное состояние дел ?

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

Чтобы сделать обмен сериализованными данными надо 1) договориться о формате 2) о пространстве имён и значений

Не вопрос - можно добавить нормальную сериализацию (к примеру в json, или любой однозначный формат) в любую утилиту. Но накладные расходы на такую сериализацию при передаче и десереализацию по приёму будут соизмеримы с использованием sed,awk для выдёргивания конкретно нужных данных из плоского текста.

MKuznetsov ★★★★★
()
Ответ на: комментарий от cvs-255

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

Доказательства.

я ничего не понял.

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

ls .\haiku-r1alpha3-vmdk.zip
выведет
Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        14.08.2012     12:44  240393915 haiku-r1alpha3-vmdk.zip
однако при передаче через пайп будет передаваться внутреннее представление

Orlangoor ★★★★★
()
Ответ на: комментарий от tailgunner

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

Zorn
()
Ответ на: комментарий от MKuznetsov

Не будут. Даже если сериализовывать в json. А с бинарным форматом тем более.

Только в существующих утилитах её нет - например затруднительно уже сделать универсальный разборщик выхлопов ps и ls например.

Нет нормальной десериализации. Сериализация есть всегда.

x3al ★★★★★
()
Ответ на: комментарий от Orlangoor

ls .\haiku-r1alpha3-vmdk.zip

обратный слэш? Винда?

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

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

На мой взгляд, было бы лучше иметь следующее: информация через пайпы передается в XML виде (или аналогичном _текстовом_ формате).

Соответственно, команда ps на выходе дает XML. Если запилить парсилку в терминал, то тогда классические команды перестанут работать, т.к. будут проблемы, например, с cat foo.xml.

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

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

А чем xml лучше, если пользователь всё равно его не увидит?

И да, в мощношелле вполне работают классические программы.

x3al ★★★★★
()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от argin

бери и делай свой линукс с sysvinit и прочими любимыми тобой решениями свобода же! Разработчики делают как им удобно, а ты видимо способен только орать «ненужно»

Dark_SavanT ★★★★★
()
Ответ на: комментарий от x3al

А чем xml лучше, если пользователь всё равно его не увидит?

тем, что a) текстовый б) если все-таки понадобится увидеть, это будет проще сделать

cvs-255 ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

man proc не дает ни одной строчки на си как читать данные акромя как парсить файлы, которые пишут данные так как вздумалось придумать разработчикам (раскою тайну - простой printf()). В этом вся проблема. sysfs мне как-то побоку пока что.

gh0stwizard ★★★★★
()
Ответ на: комментарий от Orlangoor

однако при передаче через пайп будет передаваться внутреннее представление

фича ещё не реализованна в libastral :( Утилита не имеет возможности разобраться для кого она шлёт через пайп данные.

как должен отработать конвеер : «ls | tee report.txt» ? какие данные пошлёт ls ? бинарные ?? а tee как должен их переформатить ??

MKuznetsov ★★★★★
()
Ответ на: комментарий от Orlangoor

однако при передаче через пайп будет передаваться внутреннее представление

Если заворачивать вывод ls в пайп, то он не разукрашивает вывод, если в шелл, то разукрашивает.

PolarFox ★★★★★
()
Ответ на: комментарий от MKuznetsov

Утилита не имеет возможности разобраться для кого она шлёт через пайп данные.

Какие новости! ls, тем не менее, когда добавляет esc-коды для смены цвета текста, прекрасно знает, куда она шлет данные: на терминал или нет.

geekless ★★
()
Ответ на: комментарий от geekless

Утилита не имеет возможности разобраться для кого она шлёт через пайп данные.

Какие новости! ls, тем не менее, когда добавляет esc-коды для смены цвета текста, прекрасно знает, куда она шлет

«Куда» - она знает, «для кого» - нет.

tailgunner ★★★★★
()
Ответ на: комментарий от Zorn

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

ps --enable-brainfucking

buddhist ★★★★★
()
Ответ на: комментарий от MKuznetsov

как должен отработать конвеер : «ls | tee report.txt» ? какие данные пошлёт ls ? бинарные ?? а tee как должен их переформатить ??

Хм. В том же мощношелле это решено методом ToString(), но в сабжевой реализации методов не предвидится.

x3al ★★★★★
()
Ответ на: комментарий от gh0stwizard

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

Не как вздумалось, а есть вполне адекватная документация, какие поля есть, за что они отвечают и что является разделителем.

Приведи пример, с каким файлом возникает проблема?

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от tailgunner

В терминал — значит для пользователя, нет — значит для дальнейшей обработки. Если что-то пошло не так, всегда должны быть ключи для принуждения. Как с цветом у ls.

PolarFox ★★★★★
()
Ответ на: комментарий от geekless

Для терминала можно получить его параметры, что видимо ls и делает.

grondek
()
Ответ на: комментарий от PolarFox

Проще переменными окружения. Чтобы не указывать ключ всем утилитам в конвеере.

x3al ★★★★★
()
Ответ на: комментарий от PolarFox

В терминал — значит для пользователя, нет — значит для дальнейшей обработки.

Как ты надоел своим желанием выглядеть умным.

tailgunner ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Проблем нет, проблема в том, что где-то захотелось разделять столбцы нулл-байтом, а другому удобно использовать пробелы, третьему табы. Мне лично лень в читываться и разбираться в том, как я должен парсить эти файлы. В один прекрасный день придет патч с другим символом табуляции и весь софт просто накроется медным тазом. А когда есть стандарт, средства получения данных через системные вызовы, то нет никакой головной боли.

gh0stwizard ★★★★★
()
Ответ на: комментарий от geekless

Какие новости! ls, тем не менее, когда добавляет esc-коды для смены цвета текста

только в случае терминала isatty срабатывает. А вот узнать направлен ли stdout в файл, передан в конвеер или тихо слит в /dev/null программа не может.

MKuznetsov ★★★★★
()
Ответ на: комментарий от cvs-255

обратный слэш? Винда?

Разумеется. PowerShell если не считать мертворожденного клона под mono, есть только под windows.

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

Мне в голову не приходит ни одной ситуации где присутствие парсинга по умолчанию как то мешало бы. Терминал делает toString(), в команде определено представление для этого метода.

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

Совместимость нужна не всегда, а иногда и вредна. Опять же, cat отдающая на выходе xml также несовместимое решение.

Orlangoor ★★★★★
()
Ответ на: комментарий от plm

Так написал как будто ты решаешь)может еще все и гноме ОС пользоваться будут?

RA
()
Ответ на: комментарий от x3al

Во-первых, это перенаправление в файл, а не в команду.

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

geekless ★★
()
Ответ на: комментарий от tailgunner

И если мне нужно направить 2 потока на вход одной команде...

Вручную создать именованные пайпы.

Я не вижу, как это можно в удобный синтаксис завернуть. Ты видишь?

geekless ★★
()
Ответ на: комментарий от tailgunner

При чем тут DOS, программа получит 4 имени файла, ведущих на пайпы, к которым подсоединены 4 указаных команды. man bash срочно!

geekless ★★
()
Ответ на: комментарий от geekless

Если предполагать, что дело происходит в новом баше, то никто не запрещает сделать /dev/stdin<номер>/command1 и прочее по аналогии с /dev/tcp. Да, номера выводов сдвинуть на максимальное количество входов.

x3al ★★★★★
()
Ответ на: комментарий от RA

Сравни с получением pid bash

$$

В баше короче.

Если не текущий, то pgrep bash. Опять, блин, короче. Про операции со списком процессов я уж молчу.

baverman ★★★
()
Ответ на: комментарий от Dark_SavanT

бери и делай свой линукс с sysvinit и прочими любимыми тобой решениями свобода же! Разработчики делают как им удобно, а ты видимо способен только орать «ненужно»

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

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

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

argin ★★★★★
()
Ответ на: комментарий от MKuznetsov

фича ещё не реализованна в libastral :( Утилита не имеет возможности разобраться для кого она шлёт через пайп данные.

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

как должен отработать конвеер : «ls | tee report.txt» ? какие данные пошлёт ls ? бинарные ?? а tee как должен их переформатить ??

Текстовые. Шелл в состоянии определить что tee ожидает на входе

Orlangoor ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.