[Традиции] Почему названия опций в начинаються с дефиса?

Тем, что могут быть указаны в произвольном порядке, или не указаны вообще.

Чтобы опции отличались от названий файлов.

Не понял, причём тут дефис.

какое твое предложение?

По-вашему, имя файла не может начинаться с дефиса?

У меня предложений нет. Я просто спросил, почему исторически сложилось так, что названия опций начинают с дефиса (дефисов). Интереса ради.

Научись вопросы правильно задавать. Если тебе интересно почему выбран именно дефис, причина в конструкции древних клавиатур и соображениях эргономики. Спец.символов было не так много, и минус находился на самом удобном месте.

Да не, вы не поняли. Я же пример привёл в первом посте. Зачем вообще нужен дополнительный символ (дефис или слеш или...) перед названиями опций? Что он даёт? Эргономику? — не вижу приемуществ. Исключение коллизий с именами файлов и пр. — нет, ибо имена файлов и пр. могут быть любыми.

Вопрос как-то сам возник, когда читал man ip.

Что он даёт?

Необязательные параметры и использование параметров в произвольном порядке.

find ./-name -name '-name' -size +10M -type f

как без спец. символа отличить опцию от её параметров?

По-вашему, имя файла не может начинаться с дефиса?

Может, но к чему ты это?

Проще разбирать входные данные и выбирать из них параметры, предварённые спецсимволом и их операнды без спецсимвола в зависимости от положения.

ибо имена файлов и пр. могут быть любыми.

Ты толстый тролль.

А в чём тролль? Как применить команду touch для файла с именем "-a"?

./-a

А в дружественных системах ещё и touch — -a

Тут дело не в эрногомике или визуальной красивости. Дефисами и прочими слэшами упрощается задача парсинга опций и их параметров.

Точно так же убавил работы себе и своему детищу Ларри Уолл, свалив весь этот гемор с парсингом идентификаторов на головы пользователей Perl (почему практически все другие языки прекрасно обходятся без подобного идиотизма, единым пространством имён идентификаторов?).

В никсах, в основном, приняты дефисы, в оффтопике, преимущественно, слэши. Хотя этим традициям следуют не все программы (например dd) и никто не заставляет им следовать.

Длинные опции обычно начинают с двух дефисов. Правда, не всегда.

toady2> По-вашему, имя файла не может начинаться с дефиса?

Может, но их нет. Сколько в твоей текущей системе таких файлов? 0.

А обрабатывать ты их как собираешься?

Вообще это тема второй главы книги Митчелла, Оулдема, Самьюэла «Программирование для Linux.

По-вашему, имя файла не может начинаться с дефиса?

может. И именно для этого существует «опция» --

touch — -a

Йес! кто пробовал набирать код на клаве с франц раскладкой/раскладушкой?

пальцы поберегите ))

Каким боком это относится к опциям?

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

Дефисами и прочими слэшами упрощается задача парсинга опций и их параметров.

Поясните, пожалуйста.

Чем это лучше

find '-name' name '-name' size +10M type f

Отлично, только как ты такое без либастрал распарсишь?

чтобы отличать отпции от параметров запуска (или параметров опций)

где тут ключик и где тут параметры ключиков? бред какой-то написали.

параметры тоже могут начинаться с дефиса.

Точно так же как и то, что написал power. Моя команда отличается только отсутствием дефиса у названий опций. Ср. например,

ip route add default dev eth0 table T1

ip --route --add --default --dev eth0 --table T1

Или

dd if=/dev/cdrom of=backup.iso bs=65535 conv=noerror

dd --if /dev/cdrom --of backup.iso --bs 65535 --conv noerror

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

В первом случае у тебя парсинг идет за счет порядка следования опций (что не всегда удобно, например в файнде такое точно не прокатит), во втором случае у тебя вместо минуса перед опцией = между опцией и значением.

OMG... Проехали.

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

ага, а если файл не определяется опцией? вроде
cp foo bar

cp file foo file bar что ли? а если файл называется file?

Именно поэтому приходится экранировать параметры с пробелами и дефисами, ага?

Не надо ничего экранировать. Самый логичный путь:

Команда Параметр=Значение Параметр=Значение

Параметр задаётся по правилам имён переменных в С, например.
Значение представляется либо числом, либо строкой в кавычках, по правилам того же С, например.

Экранирование параметров с дефисами относится к библиотеке парсинга опций (getopt). В принципе, можно было бы и без экранирования обойтись. С пробелами вроде бы понятно все. Или у тебя проблемы с этим?

С ними множество слов опций, по задумке, никогда не должно пересекаться с множеством остальных аргументов командной строки.

Вот в этом и загвоздка. Ладно, имена файлов нормальные люди не начинают с дефиса (хотя ненормальные — вполне могут). Но параметрами могут быть любые данные: строка для поиска, например. По идее, если уж исключать коллизии, то спецсимвол нужно добавлять как раз к *данным*, передаваемым пользователем, а не к ключевым словам программы, множество которых известно и ограничено.

И я о том же. Только вот в «=» смысла особого нет, можно и просто

Команда Параметр Значение Параметр Значение

ТС по ходу упоролся хмурым.

По идее не надо изобретать велосипед. Есть классика жанра из ЯП:

v=2.4; path="/usr"; find="text";

Только вот в «=» смысла особого нет

Для полного счастья можно было бы иметь = в качестве необязательной конфетки для более простого понимания человеком сложных команд с кучей параметров.

Для простеньких команд место для данных от пользователя можно определить положением.

Usage: foo VERSION PATH FIND-STRING [OPTIONS]
Options: foo, baz, vaz
Example: foo 2.4 /usr text foo

А если вот так

Команда Файл1 Файл2 Файл3 Параметр Значение Файл4 Параметр Значение

?

Где тут пары параметр-значение? Тут же целые наборы значений без параметра.

А вы читали сообщение на которое я отвечал?

У него «Команда Параметр Значение Параметр Значение». А у вас «значение значение значение параметр значение ...»

Ок.

Команда Х(Параметр1=Файл1 Значение1=Значение_Файл1 Параметр2=Файл2 Значение2=Значение_Файл2 Параметр3=Файл3 Значение3=Значение_Файл3) ПараметрХ = Значение_Параметр(Х) У(Параметр4=Файл4 Значение=Значение_Параметр4)

Расписал по «параметрам» и «значениям».

Что надо программе? Программе надо набор пар (параметр, значение), где «параметр» это как бы переменная, а «значение» это число или строка, задающие значение переменной. Просто набор значений имеет смысл лишь в том случае, когда имеется позиционная привязка значений к переменным-параметрам, как в вызове функции.

проектирование интерфейса консольной программы move, переписывающей из файла в файл N байт.

№1 move from="A" to="B" count=10 // аналог из С { from="A"; to="B"; count=10; }
№2 move from "A" to "B" count 10 // упрощение для неявной работы с парами без =
№3 move "A" "B" 10 // аналог вызова функции из С  { move("A", "B", 10); }

Лично мне симпатичен варианты №1 и №3. Но если параметров много, то только вариант №1.