Schemesh v0.9.0 — оболочка командной строки на Scheme

Нет конечно, просто не обновляют

Но зачем?

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

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

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

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

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

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

Разумеется для совместимости тоже, даже для неё скорее в первую очередь. Шутка ли, шелу уже почти 50 лет! Но ещё и для того, чтобы сохранить и не выкинуть всё то хорошее, что несёт с собой шел. А ещё есть третья цель, чтобы переход был максимально безболезненным, что с одной стороны обеспечит ему больше приверженцев, с другой стороны сэкономит массу усилий и времени.

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

Т.е. при переходе на zsh они bash выпилили?

Они переходили на Zsh как раз для того, чтобы избавиться от Bash. Снова вирусность GPL сыграла.

На моих древних OS X 10.6 и 10.9 bash из коробки.

Естественно на уже выпущенные версии это не распространяется, там как и прежде древняя версия Bash.

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

А что нужно менять для интерактивности? Что, а главное — как нужно поменять, чтобы… что? Зачем?

Для скриптинга использую /bin/sh (во FreeBSD это модифицированный Almquist Shell, ash, POSIX-совместимый; в Debian это dash, тот же модифицированный ash, но пошедший по своему пути), для интерактива предпочитаю TENEX C Shell (tcsh).

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

Так набрасывай на здоровье — на схеме, например. Не надо абузить интерпретатор команд %)

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

о расширении самого языка

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

Если нужно расширить возможности интерпретатора команд — просто добавляйте новые команды. В полном соответствии с Open-Closed principle (O in SOLID) — open for extension, closed for modification.

Я бы вообще пометил все погромировальные возможности шеллов как deprecated (раз уж выкинуть полностью не позволяют соображения обратной совместимости) %)

imho самая мякотка это мультилингв исполняемые файлы

шелл хорош для crud файлов и файловой системы(по факта база данных иерархо dag)

шелл хорош для crud процессов (но уже не так ибо нет полноценных графов)

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

https://en.wikipedia.org/wiki/Polyglot_(computing)

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

псс https://github.com/ioccc-src/winner/blob/master/2000/tomx/tomx.c

Жалкие остатки былой роскоши.

Расскажите больше об этом на примере Java и Go. Отчего-то, вот, решили сделать технологии, исключающие (или уменьшающие вероятность) ошибки, а не надели белый плащ со словами: „если у нас уязвимость, утечка памяти или deadlock какой, то это программист ошибся, пущая в следующий раз не ошибается“.

и будет прекрасно если это можно будет сделать в рамках того же интерпретатора, типа schemesh

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

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

Чем оно лучше емакса?

Раз уж вы спросили, естественно, такой трюк можно провернуть и в emacs:

# -*- org-confirm-babel-evaluate: nil -*-

#+begin_quote
Многие меня поносят
И теперь, пожалуй, спросят:
Глупо так зачем шучу?
Что за дело им? Хочу.
#+end_quote

Сначала запустим shell и проверим какие файлы лежат в ~/tmp~
#+name: show-tmp
#+begin_src shell :results output
  ls /tmp
#+end_src

А потом используем эти данные в scheme: результат выполнения
предыдущего блока кода сохраним в переменную ~input~ нового. Т.к. это
просто строка, никаких преобразований делать не нужно.

#+name: guile-wc
#+header: :var input=show-tmp()
#+begin_src scheme :results value
  (use-modules (ice-9 regex))

  (define (wc str)
    (length
     (list-matches "\n" str)))

  (wc input)
#+end_src

#+RESULTS: guile-wc
: 11

Плюсом получаем грамотное программирование из коробки. Минусом — размер среды исполнения.

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

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

ваять новые команды

просто добавляйте новые команды

Ты не понимаешь разницу между новыми командами (бинарниками в системе) и новыми возможностями языка? Ну понимаешь же, правда?

А что нужно менять для интерактивности? Что, а главное — как нужно поменять, чтобы… что? Зачем?

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

Так набрасывай на здоровье — на схеме, например.

не, не получится

переписать его не составит труда

переписать на чём?

Если расширить шел и стандартизировать, то это будет везде, на каждой машине, доступно так же, как и шел. Идея как раз в том что это будет новый шел, который заменит старый повсеместно (потому что будет совместим) и будет в каждом дистрибутиве, станет новым стандартом. Иначе, конечно, никому это не нужно. Иначе это будет просто ещё один экзотический интерпретатор…

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

А при коммунизме всё будет заебись.
Он наступит скоро — надо только подождать.
Там всё будет бесплатно, там всё будет в кайф.
Там, наверное, ваще не надо будет умирать.
Я проснулся среди ночи и понял, что …

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

А что нужно менять для интерактивности? Что, а главное — как нужно поменять, чтобы… что? Зачем?

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

local уже изобрели (в ash из поставки FreeBSD искаропки), set -e решает try ... catch. Остальное — думать головой!

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

Разумеется, надо расширять стандарт

Зачем? %)

Ты не понимаешь разницу между новыми командами (бинарниками в системе) и новыми возможностями языка

Языку интерпретатора команд не нужны новые возможности языков программирования общего назначения — они уже есть в языках программирования общего назначения (на которых пишутся команды). Задача интерпретатора команд — обеспечивать интерфейс между человеком и системой.

Интерпретировать, мать их, команды. Для написания новых команд уже есть языки программирования общего назначения, со всеми представимыми и даже некоторыми непредставимыми возможностями %)

решить вопрос для себя

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

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

Скрипты будут работать до тех пор пока у них будет интерпретатор

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

интерпретатор который есть везде

Возможны две ситуации: 1) вам нужно запустить ваши скрипты на ваших серверах и 2) кому-то нужно запустить ваши скрипты на своих серверах. В первом случае сервера ваши, можете поставить на них что хотите. Никаких ограничений. А во-втором — этому кому-то нужно, пускай он и напрягается, обеспечивает совместимость (либо платит вам денег, тоже дело).

просто поставить вместо шел или баш, с полным сохранением совместимости!

Вот с этим как раз проблема из-за огромного количества безмозглых дебилов, искренне уверенных что shell = bash и засравших всё подряд корявыми башизмами с шебангом /bin/sh

Эх, если бы баш разрабатывали нормальные люди вместо дегенератов и он в режиме совместимости с POSIX shell ругался на башизмы также как это делает этот самый shell… увы, думать головой при создании архитектуры ПО это удел очень немногих.

Не надо абузить интерпретатор команд

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

Зачем? %)

Потому что шел должен быть стандартным и универсальным.

Языку интерпретатора команд не нужны новые возможности языков программирования общего назначения

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

Про инит тоже когда-то так думали

Точно так же можно сказать про neofetch, который достиг предела своих возможностей в плане поддержки этой bash-портянки. Вслед за ним наверное отправится перловый inxi. Но это все не относится к пользовательским скриптам, которым вряд ли что-то угрожает.

просто поставить вместо шел или баш, с полным сохранением совместимости!

Вот с этим как раз проблема из-за огромного количества безмозглых дебилов, искренне уверенных что shell = bash

Это где так? В Дебиане /bin/sh указывает на dash, сильно не забалуешь, башизмы сразу всплывут.

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

интерпретатор который есть везде

Возможны две ситуации: 1) вам нужно запустить ваши скрипты на ваших серверах и 2) кому-то нужно запустить ваши скрипты на своих серверах. В первом случае сервера ваши, можете поставить на них что хотите. Никаких ограничений. А во-втором — этому кому-то нужно, пускай он и напрягается, обеспечивает совместимость (либо платит вам денег, тоже дело).

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

если шел не начнёт развиваться, его выкинут

У вас джаваскриптянка %)

как выкинули инит

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

И это он ещё неплохо продержался.

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

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

Между этими двумя состояниями огромная дистанция,

О чём вы? Это исправляется одной командой. Тоесть, конечно, лучше когда всё уже готово, но ввести один раз apt install $yourFavoriteLang не представляется для меня чем-то невыразимо сложным.

для тех целей, для которых я использую шел или баш.

Это для каких? Может зря я спорю, просто ваши обстоятельства не вполне понимаю.

все попытки хоть что-то как-то улучшить терпят неудачу

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

Отделить, наконец, мух от котлет.

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

ну так там в основном всё на шеле и было написано

там в основном всё на шеле и было написано

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

но ввести один раз apt install $yourFavoriteLang

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

тем более что apt есть тоже не везде

зачем усложнять

Separation of Concerns — S in SOLID.

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

Затем, чтоб больше не касаться shell и bash даже трёхметровой палкой.

Separation of Concerns — S in SOLID.

KISS

Затем, чтоб больше не касаться shell и bash даже трёхметровой палкой.

Вам шашечки или ехать?

Вам шашечки или ехать?

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

KISS

Что проще — интерпретатор команд со встроенным недоязычком горе-погромирования или без? %)

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

Лучше плохо ехать, чем хорошо идти.

Если нет рут доступа или нет интернета, то apt install $yourFavoriteLang просто не сработает.

Затем, чтоб больше не касаться shell и bash даже трёхметровой палкой.

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

Например, если нет рут доступа или нет интернета, то apt install $yourFavoriteLang просто не сработает.

Что проще — интерпретатор команд со встроенным недоязычком горе-погромирования или без? %)

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

Если нет рут доступа или нет интернета

Или нет компьютера

Nervous, где ваши крики про спутывание с языком программирования? (% Вот кому это надо объяснять, а не мне. (%

Ехать: а) куда нужно; б) безопасно; в) с комфортом.

Ехать: а) куда нужно; б) безопасно; в) с комфортом.

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

К сожалению чаще всего приходится довольствоваться меньшим…