Стиль параметров командной строки - POSIX или как?

Где-то я видел разглагольствования против java / javac, якобы использующих смесь стилей Windows и Unix, таких как

java -classpath ... -ea ... Something

ИМХО, это не микс, это так же, как findработает, не так ли? AFAIK, согласно POSIX, синтаксис должен быть таким

java --classpath ... --ea ... Something

и -abcdefбудет означать указание 6 коротких вариантов сразу. Интересно, какая версия в целом приводит к меньшему количеству опечаток и уменьшению количества ошибок

Я пишу небольшую утилиту на Java и ни в коем случае не собираюсь использовать стиль Windows, /a /bтак как меня интересует в основном Unix. Какой стиль мне выбрать?

Соглашения об аргументах POSIX можно найти в главе « Соглашения об утилитах». Стиль POSIX состоит из параметров с одной чертой, за которой следует одна буква, обозначающая параметр, а значение аргумента отделяется от параметра пробелом.

Есть исключения из правил - findнапример, - но это из-за исторических прецедентов Unix.

В X Windows (X11) используются findодинаковые опции длинных имен с одной чертой.

Опции длинных имен с двойным тире были впервые введены в GNU (после обхода с использованием +префикса).

Посмотрите этот вопрос StackOverflow для обсуждения широкого спектра известных систем обработки аргументов командной строки - их много. ( Так как это было написано, то власть имущие решается вопрос SO 367309 не был хорошо подходит для этого. Я передал ответ на другой вопрос, Каков общий синтаксис команды Unix оболочки? . )

Вы можете расширить список методов, чтобы охватить git(и ряд других систем), где вы получите структуру, такую ​​как:

• basecommand[ глобальные параметры ] subcommand[ параметры подкоманд ] [имя ...]

Может быть много подкоманд, каждая со своим собственным лексиконом опций.

Конечно, Windows использует (используется) косую черту /для обозначения параметров вместо черты -.

JCL (для z / OS, OS / 360 и промежуточных систем) имеет тенденцию использовать позиционные параметры, разделенные запятыми, и, как правило, считается не удобным для пользователя или хорошим интерфейсом.

РЕДАКТИРОВАТЬ: было отмечено, что этот стиль является GNU-изм, и что Unix на основе не GNU, как правило, используют синтаксис с одной чертой (в частности, варианты OS X и BSD).

Несмотря на статус GNU-ism, многие недавно написанные программы в стиле Unix используют этот стиль:

• --long-option для длинных названий опций,
• -s для коротких (односимвольных) вариантов,
• -abc для нескольких коротких опций без аргументов (один символ на опцию).
• Варианты с аргументами:
  • --long argили --long=argдля длинных вариантов,
  • -s arg, -sargИли ( по желанию) -s=argдля коротких опций. Это можно сочетать с другими короткими опциями, если только последний имеет аргумент.
• Один и тот же «семантический» параметр может иметь несколько псевдонимов, чаще всего короткий (более быстрый для ввода) и длинный (легче запоминаемый).

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

^- Так , например, некоторые из программ , использующих этот стиль (на моей машине Linux): ls, grep, man, sed, bashи т.д. ( EDIT: это видимо GNU-измы , хотя, BSD и OS X машина не использует этот стиль)

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

findэто очень старая программа (или, более вероятно, переписанная версия очень старой программы), которую нельзя легко изменить, чтобы использовать новый синтаксис командной строки. Слишком много сценариев сломалось бы, и слишком многие пользователи, привыкшие к старому синтаксису, будут жаловаться. javacвероятно, находились под влиянием gccи друзей, которые также следуют старому синтаксису по историческим причинам.

• Аргумент с dash-dash ( --long-arg) является соглашением GNU (см. Их реализацию getopt ).
• Команды POSIX никогда не используют двойные аргументы тире. Это относится к большинству вариантов Unix (Mac OS X, BSD), за исключением Linux, который по умолчанию использует GNU.

Для вашего проекта Java вы можете проверить GNU getopt для Java или Apache CLI . Они поддерживают обе конвенции.

Третий вариант - использовать аргументы Java VM и позволить среде выполнения проанализировать их за вас:

 $ java -Dcolor=blue

А затем в коде:

 System.getProperty("color");

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

По-разному. Я лично предпочитаю стиль POSIX, но в вашем случае я бы, вероятно, стремился к согласованности со средой, в которой будет использоваться ваш инструмент. Это означает использование соглашения Java для JAR (если вы не планируете иметь скрипт-обертку, который бы выглядел как обычная команда Unix).