Вопрос, тема обсуждения

Я очень заинтересован в создании исходного кода сценариев оболочки командной строки из кода, написанного на более надежном, хорошо работающем и независимом от платформы скомпилированном языке (например, OCaml). По сути, вы должны программировать на скомпилированном языке для выполнения любых взаимодействий с ОС, которые вы хотите (я бы предложил: более сложные взаимодействия или те, которые нелегко сделать независимым от платформы способом), и, наконец, вы бы скомпилировали их. к собственному двоичному исполняемому файлу (предпочтительно), который будет генерировать сценарий оболочки, который воздействует на оболочку тем, что вы запрограммировали на скомпилированном языке. [ADDED]: Под «эффектами» я подразумеваю задавать переменные среды и параметры оболочки, выполнять определенные нестандартные команды (стандартный «скрипт» «клей» будет обрабатываться скомпилированным исполняемым файлом и не попадать в сгенерированный скрипт оболочки) и например.

Пока я не нашел такого решения. Кажется, это относительно просто * реализовать по сравнению с другими возможностями сегодня, такими как компиляция OCaml для JavaScript.

Есть ли уже (публичные) реализации того, что я описываю?Какие еще есть возможности (очень) похоже на то, что я описываю, и чем они отличаются от этого? (Компиляция от языка к языку (от скомпилированного до sh) приходит на ум, хотя это кажется излишне трудным для понимания.)

Что я делаюне значит

Альтернативная оболочка (например, Scsh). Системы, которыми вы управляете, не всегда позволяют выбирать оболочки для пользователя или одного администратора, и я также надеюсь, что это решение для системного администрирования исключительно для других (клиентов, коллег и других), а также людей, от которых нельзя ожидать принять другую оболочку.Альтернативный интерпретатор, для которого обычно служат неинтерактивные сценарии оболочки (например, ocamlscript). Лично у меня нет проблем, чтобы избежать сценариев оболочки для этой цели. Я делаю это потому, что сценарии оболочки, как правило, сложнее поддерживать (например, чувствительны к определенным символам и манипулируют изменчивыми вещами, такими как «команды»), и сложнее создать такой же уровень функциональности, какой могут предложить популярные языки программирования общего назначения (для Например, сравните Bash с Python в этом отношении).Однако в некоторых случаях необходим собственный сценарий оболочки, например файл профиля оболочки, который создается оболочкой при запуске.Фон

Практическое применение

Некоторые из вас могут сомневаться в практической полезности того, что я описываю. Одним из практических применений этого является определение профиля оболочки на основе различных условий (например, системная платформа / ОС, на которой создается профиль, что следует из политики безопасности, конкретная оболочка, тип входа / отсутствия входа в систему). оболочка, интерактивный / неинтерактивный тип оболочки). Преимущество перед (хорошо разработанным) универсальным профилем оболочки в качестве сценария оболочки будет улучшением производительности (машинный код, который может генерировать сжатый / оптимизированный исходный код вместо интерпретации рукописного сценария), надежностью (проверка типов, обработка исключений). , проверка функциональности во время компиляции, криптографическое подписание результирующего двоичного исполняемого файла), возможностей (меньше или не зависит от пользовательских инструментов CLI, нет ограничений на использование минимальной функциональности, охватываемой инструментами CLI всех возможных платформ) и кроссплатформенных функций (в практические стандарты, такие как спецификация Single UNIX, значат очень много, и многие концепции профилей оболочки переносятся на не-Unix-платформы, такие как Windows, вместе с PowerShell).

Детали реализации, побочные вопросы

Программист должен иметь возможность контролировать степень универсальности сгенерированного сценария оболочки. Например, может случиться так, что двоичный исполняемый файл запускается каждый раз и выдает соответствующий код профиля оболочки, или он может просто генерировать фиксированный файл сценария оболочки, адаптированный к обстоятельствам одного запуска. В последнем случае перечисленные преимущества, в частности преимущества в отношении надежности (например, обработка исключений и опора на инструменты пользователя), гораздо более ограничены.[Добавлено]Вопрос о том, будет ли результирующий сценарий оболочки в какой-либо форме универсального сценария оболочки (например, сгенерированный GNU autoconf) или сценарий оболочки, адаптированный (динамически или нет) к конкретной оболочке, не является для меня основным вопросом.easy *: мне кажется, что это может быть реализовано путем наличия в библиотеке доступных функций для базовых встроенных функций оболочки. Такая функция просто преобразует себя плюс переданные аргументы в семантически подходящую и синтаксически правильную инструкцию сценария оболочки (в виде строки).

Спасибо за любые дальнейшие мысли, и особенно за конкретные предложения!