Если в баше все так плохо, не пора ли перестать им пользоваться для скриптов?

Не мешай толстить парню.

на жабке, с гипотетической библиотекой

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

showdev.sh

Вот как это делается на Java с гипотетической библиотекой:

А почему next_time просил «Производитель:», а вы выводите ″device.getVendorName()″, а не ″device.getManufacturer()″? Или там нужно ″getManufacturerName″, всё доку к этой чудо библиотеке до конца дочитать не осилю :)

как это может выглядеть на shell-е

#!/bin/bash
java ShowDevices

Вот как это делается на Java с гипотетической библиотекой

на shell-е (пусть там будут любые библиотеки, интересен пользовательский код).

Во-первых, привел гипотетическую библиотеку, а взамен хочешь реальную? Во-вторых, твоя реализация жрет overдофига памяти со своими объектами.

Жаль, что не взлетело.

А почему ты считаешь, что не взлетело?

присоединяюсь к вопросу любителям баша

Позволю себе заметить, что сама формулировка «любители баша» несколько безграмотна и повторю ответ любителей shell: Если в баше все так плохо, не пора ли перестать им пользоваться для скриптов? (комментарий)

for (Device device : os.getConnectedDevices()) {
System.out.printf(«%s from %s%n», device.getDescription()device.getVendorName());
}

интересно, как это может выглядеть на shell-е (пусть там будут любые библиотеки, интересен пользовательский код).

lsdevices --desc --vendor

Внезапно, для расширения shell пишутся команды.

еще проще: шел - окружение для запуска команд (программ)

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

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

А откуда возьмётся эта гипотетическая библиотека?

Ну я же не предлагаю писать на чистой Java аналоги скриптов. Это действительно будет наркомания. А с хорошей библиотекой уже можно думать.

Получается, что ты переложил на неё все задачи парсинга.

Парсинга чего? Будут проблемы с парсингом — напишут ядрёный модуль, который в XML-е будет выводить, проблем с парсингом не будет.

Кстати хороший пример про lspci. Из-за убогости bash-а линукс вынужден экспортировать данные в убогом текстовом формате, порой неоднозначно. Куда лучше было бы экспортировать данные в XML. Даже из bash-а было бы проще парсить не совсем тривиальные структуры.

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

Ты не отличаешь гипотетической библиотеки общего назначения от какой то лажи? Впрочем на shell уже дали ответ, как дожно выглядеть, выглядит нормально. Значит к проблемам shell ещё прибавляется проблема отсутствия нормальных библиотек, интересно, почему.

Из-за убогости bash-а линукс вынужден экспортировать данные в убогом текстовом формате

Мля, какой бред. Скажи, что ты троллишь.

Ну я же не предлагаю писать на чистой Java аналоги скриптов. Это действительно будет наркомания. А с хорошей библиотекой уже можно думать.

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

Из-за убогости bash-а линукс вынужден экспортировать данные в убогом текстовом формате, порой неоднозначно. Куда лучше было бы экспортировать данные в XML.

Клиника.

А почему бред? Одно дело под каждый результат парсить строку. Совсем другое получить объект, в котором уже есть свойства и методы, к которым обращаешься в зависимости от задачи. Например строка, как объект — сразу есть свойства (длина, чар-массив) и методы ее обработки (регулярные выражения, вверх, вниз, подстроки, перекодирование, форматирование и т.д.)

Будут проблемы с парсингом — напишут ядрёный модуль, который в XML-е будет выводить.

Куда лучше было бы экспортировать данные в XML.

Это действительно будет наркомания.

В таком порядке правильно. Даже добавить нечего.

Из-за убогости bash-а линукс вынужден экспортировать данные в убогом текстовом формате

Мля, какой бред

А почему бред?

Потому не вынужден и не из-за убогости bash.

Одно дело под каждый результат парсить строку. Совсем другое получить объект, в котором уже есть свойства и методы

Специально для тех, у кого повершелл головного мозга: Если в баше все так плохо, не пора ли перестать им пользоваться для скриптов? (комментарий)

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

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

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

Так тема про то, чем можно заменить шелл-скрипты прямо сейчас

Python-ом.

а не когда появятся библиотеки, которые будут всё оборачивать в объекты.

Будет нужда — писать библиотеки, делиться с другими.

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

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

False.

Он сделан для обработки структурированных данных

Окей, назови мне средства структурирования данных, имеющиеся в Bourne shell (не в bash). Например, в Python есть кортежи, словари, списки, классы - что есть в Bourne shell?

Python-ом.

Замечательно. Захожу я такой куда-нибудь по ssh и хочу грепнуть файл с логами по чему-нибудь да и вывести 3-ий столбец. Как на питоне выглядит связка «grep | sed»?

На повершелле это было бы что-то типа Get-EventLog -List | Where-Object { $_.Log -eq «Application» } Причем PowerShell ISE умеет в интеллисенс и это набрать можно в три раза быстрее, чем все другое на баше.

Из-за убогости bash-а линукс вынужден экспортировать данные в убогом текстовом формате, порой неоднозначно. Куда лучше было бы экспортировать данные в XML.

Это ничего, лучшие программисты планеты уже работают над переносом dbus в ядро. Потом лучшие программисты планеты будут работать (рано или поздно) над предоставлением интерфейса ядерных модулей по шине dbus, с контролем доступа, версионированностью, методами и итераторами, позволяющими перечислить хоть USB, хоть небеса, хоть богов на них, при условии что они поддерживаются ядром Linux и твой ЯП в состоянии запросить энумератор на ядерной шине и прочитать ответы.

А bash неуиноват, он убогий ровно настолько, насколько убога концепция «всё есть файл». Ну + кривой глоббинг на костылях, хрен ли вы хотели от авангарда полувековой давности.

$ grep name server.log | awk '{print $2}'
$ Get-EventLog -List | Where-Object { $_.Log -eq «Application» }

Во-первых, я не пойму, где в твоём примере вывод именно определенного столбца (+ где там указано имя конкретного файла?). Во-вторых, оно и сложнее и длиннее шелла. В-третьих, повторю, тема про замену шелл-скриптов в Линуксе прямо сейчас. Напишу ещё покрупнее «ПРЯМО СЕЙЧАС».

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

Укуренный, что-ли?

Загляни в /proc или там /sys Там полно объектов (типа /sys/bus/usb/devices/3-1) у которых есть свойства ( типа /sys/bus/usb/devices/3-1/idVendor ) и методы ( типа /sys/bus/usb/devices/3-1/remove ) к которым обращаешься в зависимости от задачи. Прям в баше, ага.

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

Это ничего, лучшие программисты планеты уже работают над переносом dbus в ядро. Потом лучшие программисты планеты будут работать (рано или поздно) над предоставлением интерфейса ядерных модулей по шине dbus, с контролем доступа, версионированностью, методами и итераторами, позволяющими перечислить хоть USB, хоть небеса, хоть богов на них, при условии что они поддерживаются ядром Linux и твой ЯП в состоянии запросить энумератор на ядерной шине и прочитать ответы.

Не взлетит, пока не будет отображения этого всего ядрёного dbus в ФС по примеру proc и sys. А будет отображение - любым шеллом можно будет это пользовать ничуть не менее удобно чем каким-нибудь пистоном.

задача в том чтобы вывести в человеческом формате, как на жабке сделано

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

Тогда давай попробуем так: мне нужно в формате, который выводит lspci и lsusb. Как такое на жабке сделать? Приведешь код?

Окей, назови мне средства структурирования данных, имеющиеся в Bourne shell (не в bash)

Их нет. Что я и пытаюсь доказать. Это язык, предназначенный для обработки структурированных данных — или, по крайней мере, чаще всего для этого применяющийся, — но средств для их обработки в нём нет.

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

/etc/fstab содержит текст или структурированные данные? Вывод ls? df? ps?

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

1) ты не дал примерчика баш кода

$ mplayer -shuffle *.flac *.mp3

2) на жабке, с гипотетической библиотекой

Кстати, на bash с гипотетической библиотекой это делается вот так:

$ do_it

$ d

P. S. Да, я стебусь. Но ведь все, что я пишу - правда, верно?

Не взлетит, [...]

А вот тут всё схвачено, мнение тоже будут спрашивать только у лучших пользователей планеты :)

ты сейчас прикольнулся?

Да это святая толстота, не сравнится с твоим жиром про необходимость каждому 32 ГБ ОЗУ.

При чем здесь /proc ?

Прям в баше, ага.

Что-то я сомневаюсь, покажи как это будет выглядеть, например надо сохранить 'ps ax' в переменную со свойствами pid и command, что бы можно было например $var.command

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

случайно, рекурсивно

жабка

Player.playDir(«/dir/», «flac, mp3», true, true);

скалка

Player.playDir(«/dir/», «flac, mp3», random=true, recurcive=true);

ну и так далее.

пожалуй что так, анонимус.

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

Player

Это тоже гипотетическая библиотека?)

При чем здесь /proc ?

При том, что там объекты с методами и пр. которых так не хватает тупорылым вендузятникам.

Что-то я сомневаюсь, покажи как это будет выглядеть, например надо сохранить 'ps ax' в переменную со свойствами pid и command, что бы можно было например $var.command

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

В данном случае у тебя под руками тот же самый /proc где есть все нужные тебе свойства для любого pid.

var="/proc/$pid"
echo "$var/cmdline"
echo "$var/status"
....

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

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

По ссылке:

BASH allows you to expand a parameter indirectly — that is, one variable may contain the name of another variable

Я написал:

nexfwall

Нет, то, что есть у Bash сейчас, ссылками назвать нельзя. Потому что передаётся название переменной, а не её адрес.

Что-то не вижу ничего нового.

Два литра чая этому господину!

Это язык, предназначенный для обработки структурированных данных — или, по крайней мере, чаще всего для этого применяющийся, — но средств для их обработки в нём нет.

Это какая-то дзен-загадка? Если в языке нет средств стрктурирования данных - значит, для обработки структурированных данных он не предназначен.

/etc/fstab содержит текст или структурированные данные? Вывод ls? df? ps?

Схоластика. Можно сказать, что даже текст на человеческом языке обладает структурой.

Почему бы не выводить нормальные человеческие предложения?

Потому что «нормальные человеческие» невозможно парсить регулярными выражениями.

/me .oO( как жаль, что в подготовке программистов нет курса «История и социология программирования» )

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

А пользоваться Жабой - это всё равно, что для купания надевать скафандр водолаза-глубоководника.

Это какая-то дзен-загадка? Если в языке нет средств стрктурирования данных - значит, для обработки структурированных данных он не предназначен.

(много тысяч лет до н.э.)
― Вот тебе палка, иди копай яму.
― Но палками неудобно копать ямы.
― Что ж поделаешь.
― В соседнем племени, говорят, изобрели такую штуку, называется «лопата».
― Они там мудаки, их вождь у меня дочь украл.
― Но палка не предназначена, чтобы землю ворочать.
― Конечно нет, она предназначена бить людей по голове.
― Но тогда она не предназначена, чтобы копать ямы.
― Ты дурак, что ли?
― Ну надо подумать об этих «лопатах»...
― Ты ведь понимаешь, что её надо вытачивать два дня? И она всё равно сломается?
― Ну так ведь... если бы у нас был какой-нибудь материал крепче дерева...
― Если бы да кабы... иди бери палку и копай яму.

Да ты писатель.

Да ты писатель.

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

Незнание системы совсем не означает что инструменты системы «неправильные».

Ну у меня нет линукса с 2009 года, откуда мне помнить тонкости, я уже не помню, как присваивать значения переменным, так V=1 или так $V=1.

Но вот из твоего примера видно, что обращаться к свойству объекта гораздо удобней, чем например парсить вывод 'ps ax | grep | sed | awk | cut | head | tail | sed | iconv | cat'. Разве нет?

Яростно плюсую. Примерно так этот тред и выглядит.

обращаться к свойству объекта гораздо удобней, чем например парсить вывод 'ps ax | grep | sed | awk | cut | head | tail | sed | iconv | cat'.

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

Но вот из твоего примера видно, что обращаться к свойству объекта гораздо удобней, чем например парсить вывод 'ps ax | grep | sed | awk | cut | head | tail | sed | iconv | cat'. Разве нет?

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

Давай ты не будешь решать за других, для чего нужен шелл?

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

Но если что - могу и к свойству объекта легко обратится.

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

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

Давай ты не будешь решать за других, для чего нужен шелл?

Я сказал, для чего шелл сделан. Для чего он тебе нужен - мне безразлично. Может, ты им кроликов режешь. В ванной.