LINUX.ORG.RU

Lua Shell

 , , ,


2

5

Контест этого топика: Леннарт теперь до эмуляторов терминала добрался (комментарий)

@EXL:

Лучше бы Lennart взялся за Bash.

@wandrien:

Там только выкинуть целиком. Я вот хочу попытаться для lua сделать обвязку для скриптинга уровня оболочки. Подобные либы на Lua есть, но качество и объем фич мне не нравится. Надо лучше. Тебе бы был интересен такой проект?


Итак, вот моя идея в общих чертах. Составные части, на которых основываться:

https://github.com/BanceDev/lush
Низкое качество сборочного скрипта. Вероятно, и кода тоже. Интересует идея в первую очередь.

https://github.com/mna/luashell
Ключевое, что нам нужно. Взять за основу. Но:

  • Нужны полнофункциональные средства перенаправления ввода-вывода, заменить эту часть API. Под капотом, вероятно. придётся делать полноценную обработку fork - настройка процесса - exec.
  • test() должен быть вменяемый, а не парсить строку по пробелам. Просто алиас для sh.cmd("test", ...).exec()
  • Форк процесса без exec в качестве элемента пайплайна на уровне API
  • Как расширение предыдущего - обёртка а ля sh.echo("text").

В качестве базового API взять https://25thandclement.com/~william/projects/lunix.html вместо https://github.com/luaposix/luaposix

Также рассмотреть для включения и/или как источник идей:


Общая идея:

  • Lua + lunix — получаем возможность писать на Луа «приложения как на Си под libc».
  • Сверху на это - форкнутый и допиленный luashell. Это ключевое.
  • Далее QoL вещи: lua-path, argparse, функции для парсинга и форматирвоания времени, функции для JSON.
  • Далее - разработать интерактивный режим для использования в качестве командной оболочки.

Продукт компилируется в статический бинарь с musl и/или cosmopolitan libc и получаем «вечный» shell. При этом весьма компактный.

★★★

Последнее исправление: wandrien (всего исправлений: 4)
Ответ на: комментарий от ugoday

Чтобы тупо перестраховываться, тоже надо хорошо знать как работает экранирование 😁

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

papin-aziat ★★★★★
()
Ответ на: комментарий от ugoday

Да, вот такого уровня решение нужно.

Но:

  1. Не в виде S-expr.
  2. Более лаконично.

Поэтому я хочу изобрести этот велосипед на Lua.

wandrien ★★★
() автор топика
Ответ на: комментарий от papin-aziat

Так. Кавычки в кавычках? Где? Что из этого следует?

Не могу мысли прочитать, напиши подробнее.

wandrien ★★★
() автор топика
Ответ на: комментарий от papin-aziat

Мне кажется, это сейчас идеальный пример получился, почему sh - говно.

Вот ты думаешь, что знаешь, как правильно пользоваться кавычками и понимать синтаксис sh, а на самом деле, с таким пониманием напишешь неверный код.

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

Тут уж хозяин-барин, на вкус и цвет все фломастеры разные.

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

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

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

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

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

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

Это все при реализации сведется к тому, что надо строить полную экосистему на самом lua, и отказываться от «юникс-утилит» стандартных по максимуму. Потому что cmd(‘gunzip’) это нет пути, нет смысла так страдать, если мы уже в lua.

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

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

Кстати, в тикле с кавычкамм тоже весело. Когда я на нём много писал, частенько спотыкался.

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

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

Не так?

papin-aziat ★★★★★
()
Ответ на: комментарий от James_Holden

Я это несколько иначе вижу.

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

При этом у тебя будет полноценный ЯП и еще QoL-фичи из коробки, такие как парсинг дат, JSON, парсер аргументов команды и т.п.

Смотри, когда мы пишем скрипт на bash, у нас два вида команд для вызова:

  1. Команды по существу. Например, если это скрипт обвязки вокруг компилятора, то логично, что скрипт вызывает компилятор. В этом суть данного скрипта.
  2. Костыли от безблагодатности bash. Чтобы просто список строк обработать, нужно лепить кучу конвееров.

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

В то же время и делать по мощности встроенных библиотек второй Ruby нам не нужно. Это оверкил. Мы не платформу для разработки веб-сервисов делаем.

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

wandrien ★★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 2)

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

Очень технологичная реализация интепретатора на чистом Си.

Сам язык базово очень прост, не требуется учить нетривиальные концепции, исторические наслоения, хитрые особенности рантайма. Куча программистов, кто уже знает язык. Куча библиотек, которые возможно взять за основу и включить в проект. Еще больше lua-библиотек, которые пользователь оболочки может использовать сам.

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

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

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

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

Да, но все же как-то надо сделать, чтобы вызов gcc скажем, не превращался в ад скобочно-кавычечный. Я не знаю как тут лучше.

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

Хотя, в принципе, наверное это не так и страшно, ну cmd() и фиг с ним.

А если вот так еще

pipe(cmd(), cmd(), cmd())

?

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

В строке описывать. Как вот с ORM когда надоедает пердолиться и подсовываешь тупо сырой SQL ему. Умный орм может даже это правильно замапить. Умный шеллозаменитель сможет разобрать строку и выполнить через собственные механизмы. А так будет порево как ни крути.

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

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

То есть, нужно раскорячиться и получить «то преимущество, что Lua - знакомый и понятный многим разработчикам язык», сохранив то преимущество, что sh - тоже знакомый и понятный многим язык.

Нужен препроцессор.

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

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

Остаётся вопрос нафига вообще там кавычки? Мне правда интересно!

papin-aziat ★★★★★
()
Ответ на: комментарий от thesis

sh - тоже знакомый и понятный многим язык

Положа руку на сердце, тут можно выделить две «части» языка. Первая - та элементарная часть, которую используют в интерактивном режиме. Ее все знают и понимают. Вторая - тяжелое скриптование - это хтонический ад.

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

Положа руку на сердце, тут можно выделить две «части» языка. Первая - та элементарная часть, которую используют в интерактивном режиме. Ее все знают и понимают. Вторая - тяжелое скриптование - это хтонический ад.

100%

И я не вижу причин, почему бы ради первой части просто и не пользоваться дальше bash/zsh/whatever.

Не, если кто-то придумает лучше - отлично.

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

А вот для скриптов уйти от хтони мне бы очень хотелось.

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

sh - тоже знакомый и понятный многим язык.

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

ugoday ★★★★★
()

@James_Holden, @ugoday

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

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

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от wandrien

И я не вижу причин, почему бы ради первой части просто и не пользоваться дальше bash/zsh/whatever

Так можно ведь, допустим, в твою lua среду, впилить мини-sh в виде функции shell(). Которая будет парсить однострочники, понимать пайп и перенаправление в файл, но не будет поддерживать циклы, ифы, переменные и прочую более сложную логику.

Тогда в скрипте можно делать

shell("gcc -O2 myprog.c -o myprog")

При этом, строку передаваемую в shell можно формировать просто как строковую переменную lua, в скрипте.

А в интерактивной оболочке (!) сделать простую логику. Если мы туда вводим тупо

gcc -O2 myprog.c -o myprog

То оболочка видит, что это не валидный код lua, и заворачивает все как строку в вызов функции shell(). Если валидный код lua - кидается в repl.

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

изобретать с нуля некое «тикле-подобие с пайпами», мне не охота вот вообще.

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

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

В свою очередь я соглашаюсь, что для однострочников и приравненной к ней мелюзги sh вполне годится. А для диалогового режима работы, хороший шелл с подстановками и автодоплнением (т.е. zsh) и вовсе идеальный выбор.

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

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

Я пробовал.

Проще достать обратно bash и страдать на его закорючках дальше.

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

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

Так это же круто, что можно очень плохо знать баш, но успешно работать в консоли. У конкурента должна быть такая же особенность. Хорошо знать луа совсем не хочется, если честно.

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

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

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

Так проблема то, по сути, не с работой в консоли. А со скриптованием. В консоли работать легко можно.

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

Так уже разобрались вроде, что склеивание пайпами больше нужно в интерактивном режиме. А в скриптах, можно и без этого, или тупо pipe(cmd(), cmd(), cmd()).

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

Но это уже говнина. А если добавить сюда разделение потоков?

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

Типичный цикл разработки скрипта на sh:

  1. Ну это просто. Я же в голове представляю, какие команды и как надо вызвать, чтобы получить результаты. Прототип пишется за 5 минут прямо в терминале.
  2. Потом ты начинаешь делать к нему настройки. Если это скрипт, а не просто одноразовый кусок кода, у него должны быть крутилки для получения настроек от среды. Вот эту команду так вызывай. А вон ту вот так. Вот эти переменные среды учитываем.
  3. Потом ты пишешь обработку ключей запуска.
  4. Потом встроенную справку.
  5. Потом еще какую-то херабору.

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

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

В итоге скрипт примерно на 90% состоит из страданий на bash вокруг обработки строк, чисел и т.п. И только на 10% из сути, ради которой всё затевалось.

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

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

Я повторю вопрос: что именно ты изобретаешь и чем оно отличается от «прямо сейчас воткнуть первой строкой шебанг и писать на чем угодно»?

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

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

Там не потому клеить неудобно, что синтаксис мешает, а потому, что у тебя нет контроля над fork(), dup(), exec() и т.п.

Батарейки, чтобы окно нарисовать в язык завезли, а чтобы с Unix-like API работать - нет.

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

писать на чем угодно

Можно, но там будешь конвейеры руками строить портянками на 100 строк. В этом же проблема, как я понимаю.

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

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

А я думал, что я просто тупой, раз не могу понять перловку. Оказывается, не только меня это бесит! На bash я начал писать, только когда появился GPT. Но это еще хуже, потому что я не могу понять, что он мне там нагенерировал, и не удалю ли я корень сейчас.

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

Типичный цикл разработки скрипта на sh

Лол, как это знакомо. Зато можно выучить наконец-то баш в процессе. Правда через месяц снова забыть.

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

Я повторю вопрос: что именно ты изобретаешь

Интерпретатор Lua, укомплектованный прямым доступом к API операционной системы и библиотеками, облегчающими жизнь по написанию интеграционных, обвязочных скриптов. Завернутый в статический билд, чтобы «установка пакета» сводилась к копированию единственного файла на любую AMD64-совместимую машину.

В ОП это написано.

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

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

bread
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.