Надуманные проблемы такие надуманные.

Для читаемости придумали длинные опции.

CLI: easy-to-read vs easy-to-write?

GNU style vs BSD style.

Длинные опции хороши в скриптах, когда понятность имеет приоритет над объёмом писанины. В интерактивном шелле обычно удобнее короткие, за исключением случаев, когда у программы их очень много, плюс всё не запомнишь, только часто используемое.

Ну и открой для себя автодополнение параметров шеллом.

Что за дроч на читается почти как английский текст? Как без минусов явным образом указать что тебе нужно натравить твою программу на файл abc?

Короткие это когда -h vs --help, а экономить на одном единственном '-' как-то через чур.

Я топик прочитал после написания ответа %) Нездоровые там фантазии.

Если бы вы прочитали сообщение, то увидели, что все «пользовательские» аргументы (d_arg, 42, infile, etc.) идут после аргумента-ключевого слова.

И даже когда синтаксис построен таким образом, что на данном месте может быть как ключевое слово, так и какое-то (почти произвольное) слово от пользователя, то минус исключают коллизии? Классический UNIX почти всегда нам предлагает в этом случае граблю "--".

Нормальные консольные утилиты наиболее популярные параметры поддерживают как в длинном так и в коротком варианте, типа: -d --detail

То есть у твоей утилиты как класс отсутствуют дефолтные аргументы (то есть те которые применяются без ключей) и флаги которые не требует аргументов (типа -h, -v)? Минус не исключает коллизии, но существенно снижает их вероятность. В общем, воля ваша, что-то вы несусветное придумали.

> С другой стороны, наиболее easy-to-read вариант может быть типа

foo --disable-overwite --enable-make-backup --with-method=lzma --with-level=42 from=infile to=outfile

автолулз рулит ;)

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

Короче, какой вариант синтаксиса лучше для консольных программ? И почему.

Классический для GNU. Длинные --ключи для всех опций. Короткие -к -л -ю -ч -и для самых используемых. 1. Это привычно. 2. Это достаточно удобно. 3. Есть готовые парсеры. 4. Нет особых причин менять шило на мыло.

Почитай что-нибудь о синтаксическом анализе и подумай. Он придумал вполне «сусветное». Но ненужное, впрочем.

Мне одному кажется, что эта тема уже не в первый раз всплывает в техразделах?

По теме:

Лучше тот синтаксис, который принят сейчас.

Так я разве говорю, что этот вариант совсем нельзя разобрать? Можно. Но во-первых сложнее (любой аргумент это потенциальная комбинация ключей), во-вторых растёт число коллизий (правда положив руку на сердце, не очень сильно), в-третьих это существенно снижает эффективность автодополнения в шелле.

Вот, это уже по делу.

Короче, какой вариант синтаксиса лучше для консольных программ?

Разумеется, easy to write.

И почему.

Потому что они консольные. Их пишут. Один раз. Зачем их читать-то?

Неужели я буду первым?

man getopt !!!!!11111

Ничто не мешает реализовать оба варианта как альтернативы.

1. изитурайт трудно запомнить. приходится постоянно делать --help или man, что в итоге сводит выигрыш во времени набора на нет.

2. читать нужно уметь а скрипка.

пардон за опечатки. sapienti sat.

изитурайт трудно запомнить

а правда, что виндузятники в пауэршелле пишут Set-Location всякий раз вместо cd? то, что часто используется, хорошо запоминается. в математике компактных обозначений очень много, и никто не жалуется.

dd if=... of=... topt=...
Стиль dd совмещает преимущества.

easy-to-use

http://img189.imageshack.us/img189/4512/feh024996000001screensh.png

Про «пауершелл» не знаю. Но готов поспорить, что >90% всех установленных программ вы *часто* не используете. И, соответственно, без предварительного чтения инструкции использовать не сможете.

А почти все из оставшихся 10% — классические юниксовые программы, с классическим easy-to-write BSD-синтаксисом, пробороздившим мозги любому юниксеру. Тут ничего не изменить, да и не надо.

Я говорил об «обычных» пользовательских программах, которые составляют бОльшую часть $PATH и которые не используются бОльшую часть времени.

Ещё один аргумент против «вшитого в синтаксис» easy-to-write вытекает из того, что все нормальные шеллы имеют настраиваемые автодополнения. Поэтому easy-to-write реализуется автоматически:

# В скрипте (70 нажатий клавиш). Не надо мана, чтобы понять, что делает эта команда
$ foo -overwite +make-backup method lzma level 42 from infile to outfile

# В интерактивном шелле, тут "~" = клавиша Tab (44 нажатия). К тому же нормальные
# шеллы будут выдавать список возможных дополнений при наборе начальной
# части слова (а на "пустом месте" вместо списка вариантов можно выводить краткий "Usage"
# (SYNOPSIS мана) -- получаем интерактивную справку.
$ foo -o~ +m~ m~ l~ l~ 42 f~ infile t~ outfile

Интереса ради, сравним с классикой:

# Classic BSD (42 нажатия без учёта <Shift>). Не дай бог понадобится разбирать скрипт,
# написанный в таком стиле, напичканный незнакомыми программами.
$ foo -Om -M lzma -l 42 -i infile -o outfile

# Classic GNU (83 нажатия). Слишком избыточно (даже если не использовать --with-*,
# --enable-*, etc. в стиле автотулз).
$ foo --no-overwite --make-backup --method=lzma --level 42 --from=infile --to=outfile