Почему же? Уж сколько раз твердили миру, что все эти system(3) до добра не доводят. Но традиции Unix Way не позволяют пересмотреть ситуацию и придумать лучший API. Юниксовые программисты потеряли запал и ни на что не годны.
Вот есть совершенно бессистемно "спроектированный" исторический мусор терминала, со всеми этими esc-последовательностями, вендорскими расширениями, отсутствием стандартов и вообще беда. Но были люди в наше время, запилили termcap, terminfo, curses... Создали базу данных терминалов -- terminfo. Это не сняло всех проблем, но, по-крайней мере, стало возможным использование множества различных капабилитей разных терминалов, без необходимости запариваться при этом на совместимость с разными вендорами. Были люди в наше время.
Но сегодня богатыри перевелись и уже нет у них запала запилить костылик a la terminfo для запуска команд. Создать базу данных разных команд, для каждой команды список типизированных аргументов (бинарная опция --help, перечислимая опция --codec=... со списком возможных значений, имя файла (существующего, не существующего, доступного за запись...), строка,...), написать библиотечку, которая будет в рантайме проверять аргументы, форматировать их так, чтобы программа не восприняла бы имя файла за ещё одну опцию, предоставить API для всего этого, чтобы программер писал бы что-нибудь типа:run_program(tar, {.short_options_batch="-xOf", .archive=archive, .filename=filename}) и пускай библиотека консультируется с базой данных команд и соображает как раскрыть макрос run_program, чтобы сгенерить код, который будет генерить строчку для system(3), которая будет делать именно то, что задумано программистом, а не произвольные вещи, определяемые содержимым переменных archive и filename. Но для юниксвея сегодня традиции важнее всего остального и отказываться от system никак нельзя. Впрочем, тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями. Хотя, во всяких там python'ах, которые действительно позволяют получить приятный API для таких вещей (именованные аргументы функций, например, очень уместны для этого), почему-то все так же продолжают пользоваться system. Мельчают люди.
|
