> В случае же с базой всех возможных команд, это уже задача принципиально
> другого уровня:
> Во-первых, необходимо регистрировать каждую команду в системе при установке, кто должен
> это делать? Разработчик программы? Мейнтейнер?Для начала разработчик программы. Со временем мейнтейнеры дистрибутивов начнут помогать. А в далёком будущем автор любой шелл-утилиты будет создавать к ней файлик с описанием опций.
> Во-вторых, необходимо перед вызовом каждой программы проверять корректность её аргументов
> по базе, и не давать ей запуститься, если параметры не правильные.
> И это необходимо в рантайме, хотя бы потому, что существуют языки
> shell. База будет большой. Сильно увеличится время запуска.
База будет большой, и что с того? До тех пор, пока программист вызывает команду известную на этапе компиляции, поиск по базе можно выполнить на этом же этапе компиляции. И большую часть проверок провести там же. Это даже с C возможно подчастую: компилятор может выполнять простенький код на этапе компиляции, с тем чтобы заменять код результатом его выполнения.
Проверка трёх аргументов для tar, мне кажется, может быть выполнена в рантайме за время превосходящее время сисколлов fork/exec не более чем на порядок. А может быть даже быстрее -- сисколлы, с их переключением контекстов, вообще тормозные.
> В-третьих, даже если написать типизированный shell с выводом типов по хиндли-милнеру,
Ни о каком шелле я не говорил. Шелл и запускаемая программа как-то проверяют синтаксис командной строки и аргументов -- но этих проверок явно недостаточно. Речь о том, чтобы проверить аргументы ДО того, как они будут переданы в legacy шелл и legacy утилиту. Ошибки вида "Invalid file name starting with `--'" будут возникать в недрах библиотеки до того как будут выполнены fork и exec для запуска шелла или legacy утилиты.
> В-четвёртых, что вы с этой вашей базой будете делать с программами, в
> которых аргументы представляют собой язык? В аргументах которых можно задавать другие
> команды? Ну тот же "bash -c <command>", тот же "find ...
> -exec <command>"? Это ж пипец, предусмотреть все случаи.
Эта проблему нельзя решить на 100% -- я согласен. Даже изобретение такого языка описания аргументов утилит для базы данных, который, с одной стороны, справится с 90% утилит, с другой стороны будет не слишком заморочным, потребует долгой возни. Это оптимизационная проблема, надо найти компромисс между простотой и гибкостью. Но я отмечу, что помимо декларативного описания аргументов в базе, возможно использовать ad hoc код для отдельных утилит, который будет особым образом работать с выбранной утилитой. Кроме того, задача не сделать так, чтобы любая осмысленная комбинация аргументов для любой утилиты была бы возможна, задача сделать так, чтобы была достижимой любая цель, ради которой вызывается утилита. У меня нет готового осмысленного примера, для пояснения этого, но в качестве слабоосмысленного примера: если мы не дадим способа объединять короткие опции в один аргумент, и если необходимо передать -jxf в команду, то будет переданы -j, -x, -f по отдельности, то это вполне допустимо.
Ну и финально, в дополнение к safe API для вызова дать unsafe API для обхода такого рода случаев. Главное чтобы этот API был бы более геморройным для программиста и провоцировал бы его поискать обходные safe пути, которые выполнят все проверки. Может вовсе не обязательно запускать bash -c для достижения цели?
> В-пятых, не все команды принимают аргументы, следуя рекомендациям posix. tar, unrar, например...
> Как эти программы в базу вносить?
Функционально, а не декларативно. Взять и написать функцию check_args_unrar(...).
> Вы предлагаете создать базу программ, но это лишь способ перенести проверку с
> программы на какой-то внешний механизм. Спрашивается, зачем? При разработке Unix долго
> думали, как это сделать, и как видите, оставили это на усмотрение
> разработчиков. И это самый правильный путь, потому что программ великое множество,
> и список их постоянно пополняется, так что за всеми не уследить.
Программ великое множество -- бесспорно. Но уследить за всеми возможно: мейнтейнеры дистрибутивов этим занимаются постоянно. Кроме того, этим могут заниматься сами разработчики программ. Написал новую утилиту? Создай запись к базе данных.
Ну и финально, можно же взять и создать декларативный язык описания опций командной строки, который затем можно скомпилировать в декларации C, C++, в Python код, во всё что угодно ещё, и заодно компилировать его в описание для базы данных утилит. Иногда это можно сделать и без создания нового языка, но дополняя старый: если взять тот же argp.h и дополнить его описания аргументов ещё одним полем -- типом аргумента, то мы получим описание, которое можно легко и непринуждённо скомпилировать в то, что надо нам.
> Вы предлагаете создать базу программ, но это лишь способ перенести проверку с
> программы на какой-то внешний механизм. Спрашивается, зачем?
Затем, что программа не может выполнить проверку полностью, в силу потери информации при передаче аргументов. Собственно, проверки того, что программа и так проверяет вовсе не обязательны. Главная задача -- это чтобы API вызова внешней программы позволял бы писать такой код вызова, который бы не делал ничего, что неочевидно из этого кода. Если я написал `tar filename', то должен быть вызван tar с аргументом-именем файла. Даже если filename -- это переменная содержащая строчку полученную в рантайме извне программы. Либо будет вызыван tar с аргументом-файлом, либо он не будет вызван, а вызывающий код получит код ошибки. Второе может быть, например, если tar невозможно вызвать с именем файла начинающегося с --, если tar любой аргумент начинающийся с -- трактует как опцию.
То, что предлагает unix, требует от программиста делающего вызов system(3) выполнять все эти проверки каждый раз одну за другой, ничего не забывая, помня все подводные камни. Подводные камни общего случая, и подводные камни свойственные конкретной утилите, которую он вызывает. Помнить он естественно не помнит, потому вся надежда на то, что он внимательно и вдумчиво прочитает мануал к утилите, заметит там все возможные способы ошибиться, и напишет без ошибок. Ха-ха. Это каким же надо быть оптимистом, чтобы полагать, что хотя бы в 10% случаев код вызова внешней утилиты будет написан без ошибок с первого раза?
И зачем нужно каждому программисту вызывающему tar тратить своё время на выяснение всех подводных камней, если можно проделать это единожды и дать этому программисту готовый код, обходящий все подводные камни?
Вариант для распечатки
(ok), 15-Июл-17, 05:34 
