OberonCore

Вот скажем я запускаю расчет:


Где сам bbcb при том использует переменные окружения:


А аргументы для расчёта уже предаю в виде аргументов командной строки.
Обращаюсь к ним через Kernel.argc Kernel.argv
Это была рабочая ситуация, когда отлаживал MPI.

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

Но для чтения через командную строку тоже не против добавить режим в HostEnv, чтобы он проверял "/BB_SECONDARY_DIR" или "--BB_SECONDARY_DIR"

И где-нибудь из-за такой ошибки

Что-то может пойти не так, и ББ об этом не сможет сообщить

На конференции "Доверенные системы" в этом году и ФГУП НТЦ "Атлас", и ИСП РАН в своем плаче о том, как тяжело сделать хоть немного доверенной экосистему GNU, особо обращали внимание на переменные окружения как фактор всяких уязвимостей.

С точки зрения системы и переменные окружения и параметры командной строки являются законным способом передачи параметров в программу. Переменные окружения были задействованы в Linux в свое время просто как единственный адекватный вариант, потому что доступ к аргументам командной строки был проблематичен. Теперь, когда Trurl написал новый линкер, эта проблема ушла. Но это не противоречит тому, чтобы навести порядок в Host, поместив извлечение параметров в отдельный модуль.

Спасибо, Евгению, теперь Блэкбокс в Linux умеет читать еще и параметры запуска через аргументы командной строки:


Чтобы работала переменная BB_SECONDARY_DIR нужно обязательно указать BB_PRIMARY_DIR.

Но если BB_PRIMARY_DIR задана через переменную окружения, то тогда достаточно указать только BB_SECONDARY_DIR


Графический пример:


Всё это работает с версии 1.8-a1.015

luowy в чате предложил оформить также более традиционные интерфейсы. И назвать Args по аналогии с другими Оберон/Модула системами.



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

Раз в Блкэкбоксе фактически уже есть реализации для этого интерфейса. То не вижу из каких соображений не добавить такой интерфейс.

Если есть люди, которые считают, что взятие переменных окружения и аргументов командной строки — это Bells & Whistles и, что мы превращаем Блэбокс в Visual Studio, тоже выскажитесь на этот счёт.

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

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

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

Это нужно, чтобы уменьшить использование ядра напрямую. Сейчас люди просто используют Kernel.argc Kernel.argv
Код получается не кросс-платформенным, и это плохо. Для решения прикладных задач надо контролировать откуда пришел параметр, из командной строки или переменной окружения. Для настроек Блэкбокса в общем-то не важно. Так что ваша идея с GetPar я считаю отлично решает проблему настройки. Но раз она реализует и решает ходом другую проблему, то давайте решим и её также.

Согласен с тем, что в некой абстрактной ОС нет понятия переменной окружения и нет понятия аргументов командной строки. Так что возможно в System не лучшее место.
Тем не менее в Dialog, например есть глобальная переменная commandLinePars.

Раз необходимо обобщение, то я бы тогда сделал параметры двух видов:
- параметры окружения (операционной системы, сессии, пользователя)
- параметры запуска программы (аргументы командной строки, файлы с конфигурацией запуска и т.п.)

В общем они все параметры, так что получается в интерфейсе три процедуры для чтения:
- GetEnv
- GetRun
- GetPar, как обобщение первого и второго.

Плюсую. Это дает возможность абстрагироваться от источника настроек тем, кому это не важно; а кому важно - если, напр, я в Лин пишу утилиту командной строки - будут напрямую обращаться к параметрическому бэкэнду. Или с парой ключ/значение можно сообщать, откуда оно взялось.

Располагаться этот интерфейс должен в Dialog, кмк - если сохранять преемственность, поскольку там сейчас чтение параметров комстроки.

Теперь надо вот так запускать Windows версию в Wine


Раньше вот так работало

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

Свежий пример уязвимости на переменных окружения как часть общей картины проблемности этого типа данных:

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

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

Позволить программам на ББ получать аргументы командной строки в чистом виде через единую (кроссплатформенную) переменную или процедурный вызов.

С помощью HostEnv cделал, чтобы Dialog.commandLinePars корректно устанавливался на всех платформах. Вместо HostMenus установка происходит в HostDialog, так что в консольной версии эта переменная теперь тоже корректно устанавливается.

Ещё вопрос возник. HostMenus содержит следующую возможность:

Как вы относитесь к этой функциональности? Сейчас она поддерживается только в Windows версии.
Может быть убрать это из Блэкбокса? Есть ли прецеденты, что кто-то пользовался этим?

Так Env вроде бы работает универсально и с переменными окружения и с параметрами строки. Нет?

Ну только он HostEnv, а использовать модули подсистемы Host нельзя в проектах. Нужен тогда какой-то интерфейсный модуль Env.
У Артура похоже желание самому как-то парсить командную строку.

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