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

а как быть с опциями (т.е. всякими модификаторами)? а также в случае сложных программ могут потребоваться субкоманды, опции к ним, субкоманды и опции и т.д.

рассмотрим гипотетическую программу для поиска книг по разным полям (author, title, year...). к каждому полю можно указать метод сравнения (regexp, glob...), а также опции типа [-+]case-sensitivity. например я хочунайти книгу автора ААА, где ААА — регексп без учета регистра, заголовок ЗЗЗ, где ЗЗЗ — glob с учётом регистра, но издание не третье.

[code]book find author regexp -case :AAA and title glob +case :ЗЗЗ and not edition :3[/code] это мой вариант как это описать в строке. двоеточиями выделяются неключевые слова (данные от пользователя) для исключения коллизий (опции и метод сравнения — необязательным параметры).

как можно улучшить синтаксис? и можно ли как-нибудь разумно описать ту же команду как список пар переменная--значение?

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

Вот именно. Название опции в любом случае, и в предложенном вами тоже, может совпадать с именем файла. Фишка в том, что в случае с дефисом конфликтов будет меньше, чем без него.

Потому что это ключи. Внезапно

Потому что гладиолус. Внезапно.

Не понял, так зачем вылезаешь?

Фишка в том, что в случае с дефисом конфликтов будет меньше, чем без него.

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

Вы тему читали? Так зачем вылезаешь?

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

Те же яйца - вид сбоку. Плюс очевидное неудобство:

find -name "myname*" | tar -czT - >mytar.tgz

и т.п. не будет работать без шаманства с именами файлов.

Единственный способ исключить конфликты - чёткая структура параметров (ключ=значение, например), но для человеков такое будет неудобно.

Можно выйти следующим образом.

find name FILE...

где FILE может быть

• Именем файла. В этом случае к началу нужно добавить, скажем, двоеточие, чтобы исключить конфликты с ключевыми словами.

  find name :blablabla.txt :bububu.txt

• «stdin» — каждая строка stdin будет интерпретироваться как имя файла.

  ls *.txt | find name stdin

• «args» — все последующие аргументы будут интерпретироваться как имена файлов.

   find name args *.txt

• ... другие полезные штуки. У нас тут простор большой, нам уже не надо беспокоится о конфликтах с параметрами пользователя.

Кстати, о сокращениях. В классическом варианте длинные опции часто имеют односимвольные синонимы, которые часто не совпадают с первой буквой длинной опции (поэтому быстрее набрать длинную, чем вспоминать короткую или листать man). По-моему, более удобный вариант состоит в том, чтобы просто обрезать ключевые слова, пока это не вызывает двусмысленности. Например, если программа допускает две опции «remove» и «rename», то их можно сокращать до «rem» и «ren».

Единственный способ исключить конфликты - чёткая структура параметров (ключ=значение, например), но для человеков такое будет неудобно.

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

Или просто переложить раскрытие glob'ов с шелла на саму программу.

find name ':myname*'

«stdin» — каждая строка stdin будет интерпретироваться как имя файла

«args» — все последующие аргументы будут интерпретироваться как имена файлов.

Костыли костылики. Как быть с этим:

find -name "*.[ch]" -o -name "*.lisp"

переложить раскрытие glob'ов с шелла на саму программу.

find и так сам глобы обрабатывает.

с чем именно?

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

Почему негры хорошо бегают, а белые хорошо стреляют ?
Так исторически сложилось.
Кому-то в начале понравилась концепция - короткие параметры с одним дефисом, длинные с двумя, другие подхватили по аналогии.
Причины нет.

с чем именно?

«args» — все последующие аргументы будут интерпретироваться как имена файлов

find -name "*.[ch]" -o -name "*.lisp"

запишите с вашим args

Я же писал, что глобы можно отдать как есть программе, а не раскрывать шеллом. То бишь

find name ':*.[ch]' or name ':*.lisp'

В принципе даже ':' перед параметрами не обязательны, если не возникает конфликта с ключевыми словами, которые могут быть в том же месте. То есть можно воспринимать ':' только как насильное указание рассматривать этот аргумент не как ключевое слово.

Причины нет.

кроме желания как-то отделить одни лексемы от других, конечно, причины нет.

Я же писал, что глобы можно отдать как есть программе, а не раскрывать шеллом

Я же писал, что find и так сам обрабатывает глобы.

Одинарные кавычки принципиальны

В данном случае, не принципиальны - глобы не раскрываются в любых кавычках. Однако, сейчас у меня есть выбор, какие глобы раскрыть в шелле, какие передать find'у, а в вашем варианте выбора нет.

Однако, сейчас у меня есть выбор, какие глобы раскрыть в шелле, какие передать find'у, а в вашем варианте выбора нет.

Мы, наверное, не понимаем друг друга. Давайте так: напишите, как вы раскроете глоб * шеллом в вашем варианте (заодно предположим, что в ./ лежит файл, скажем, "-exec").

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

Да, извиняюсь, действительно не раскрываются. Буду знать. Но суть не в этом.

Тред полон одаренными программистами, которым дефисы нужны для простоты парсинга. OMG.

двоеточие,

В начале имени файла встречается чаще чем дефис.

ls *.txt | find name stdin

Для этого уже есть стандартная запись 'find name -'. Более того умные программы сами могут догадаться что у них пайп на вводе.

И далее по тексту такая же чушь. Параметрами команды могут быть как *опции*, так и позиционные аргументы, это удобно, чего-нибудь нового и удобного придумать сложно. Разве что улучшить cli отдельных конкретных команд.

В общем вы правы, что можно выделять имена файлов спецсимволом, а ключи никак не выделять. Я лишь хотел указать на одну проблему: как поступать с именами файлов, если их нужно подставить в командную строку в результате глоббинга, или подстановки (cat `ls` напрмер), или подачи имён файлов на stdin. Получается, что ls должна выдавать имена уже с двоеточиями вначале и любая команда должна изменять имена подобным образом или это должны делать вызовы readdir, stat и т.п. функции и системные вызовы ядра. Плюс проблемы при портировании программ/библиотек с/на другие системы. Не слишком ли много геморроя?

В начале имени файла встречается чаще чем дефис.

Вы не поняли суть его введения. Там хоть букву «a» можно добавлять, ничего не изменится, если мы договоримся, что все ключевые слова и опции с этой буквы не начинаются. К тому же выше написано, что этот префикс опционален — только для того, чтобы показать, что аргумент не является ключевым словом, когда возникает двусмысленность. Однако тут у нас появляется хорошая возможность: мы можем свободно вводить новые ключевые слова типа «stdin», «from-file», «args»...

Для этого уже есть стандартная запись 'find name -'

Про это уже было. Я извращенец и в ./ у меня лежит файл '-'.

Параметрами команды могут быть как *опции*

Я извиняюсь. По опциями я имел в виду любые ключевые слова программы, то есть противоположность «данных» от пользователя (имён файлов, строк для поиска, чисел...).

Разве что улучшить cli отдельных конкретных команд.

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

Получается, что ls должна выдавать имена уже с двоеточиями вначале

Нет. Двоеточия нужны только в командной строке, чтобы отличить эти аргументы от ключевых слов. Причем, если и так ясно, что это не ключевое слово, то : можно и не писать.

как поступать с именами файлов, если их нужно подставить в командную строку в результате глоббинга

Лучший вариант — перенести обраотку глобов на программу. Когда это делает шелл, то ещё возникает проблема в том, что разные шеллы их по-разному раскрывают. Например, по дефолту zsh рекурсивно раскрывает, а bash — нет. И вообще, тогда нет зависимости от шелла. А в программе можно ввести дополнительные опции, чтобы модифицировать метод раскрытия (регэкспы, глобы, расширенные какие-нибудь глобы и т.д.).

Двоеточия нужны только в командной строке, чтобы отличить эти аргументы от ключевых слов

Вы наверное по диагонали читаете?

cat `ls`

делает подстановку в командной строке и получается что-то типа:

cat file1 file2 file3

cat :file1 :file2 :file3

cat `ls`

Если в ./ нет файлов, конфликтующих с ключевыми словами программы, то двоеточия не нужны.

кто будет приписывать это двоеточие: ls, libc или ядро?

А кто будет приписывать "./" к именам типа "--kill-the-world"?

Вообще, эти inline-подстановки выводов программ полезны только в примитивных случаях. Так косяк на косяке. Ну, навскидку

// myecho
#include <stdio.h>

int main(int argc, char **argv)
{
    int i;
    for (i=1; i<argc; ++i)
        printf("%s\n",argv[i]);
    return 0;
}

$ mkdir test
$ cd test
$ touch 'hello world'
$ myecho `ls`
hello
world

Изначальный вопрос состоял в причинах использования "-" перед опц^W ключевыми словами.

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

Тред полон одаренными программистами, которым дефисы нужны для простоты парсинга. OMG.

Сказал бы ты это Томпсону в 1969, когда он работал на PDP-7.

Для справки: быстродействие 285К сложений в секунду (целочисленных), максимум 64К памяти (18 битной).

Блин, ну вы хотя бы темы почитали что-ли.

Блин, ну вы хотя бы темы почитали что-ли.

То что ты предлагаешь никак не лучше существующей схемы. И все твои проблемы связаны с использованием cli какой-то одной программы.

Сказал бы ты это Томпсону в 1969

Он бы посмеялся, потому что парсер командной строки ищет не дефисы, а целиком опцию, что никак не легче.

Вы намекаете, что мы должны теперь вечно следовать традициям, приобретённым из-за тормознутости древних компьютеров?

А кто будет приписывать "./" к именам типа "--kill-the-world"?

Ненужно приписывать

cat -- `ls`

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

Это уже дело техники:

find -maxdepth 1 -type f -print0|xargs -0 cat --

Я вам cat `ls` написал для простоты понимания проблемы.

потому что парсер командной строки ищет не дефисы, а целиком опцию, что никак не легче.

Это он сейчас ищет, а в 1969 было не до того.

Вы намекаете, что мы должны теперь вечно следовать традициям

Вы так говорите, как будто это что-то плохое.

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

И в чем сакральный смысл менять — на args?

А почему команда всегда на первом месте?

Компьютеры становяться дешёвыми и быстрыми, так зачем оставлять атавизмы?

Затем, что есть огромное количество гораздо более насущных проблем, а то что вы предлагаете, это смена одной проблемы на другую и ещё одну = ненужно.

становяться, начинаються

А ведь опции - это почти как родной язык...

Может у тебя еще и сырцы есть, 69ого года, в которых опция определяется по первому байту? А то несколько голословно.

Может у тебя еще и сырцы есть, 69ого года

В 69 году сорцы были на асме если что. Более-менее к современному виду unix пришёл позднее. Вот, к примеру, 75 год: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/ls.c

if (--argc > 0 && *argv[1] == '-') {
		argv++;
		while (*++*argv) switch (**argv) {
		case 'a':
			aflg++;
			continue;

		case 's':
			sflg++;
			statreq++;
			continue;

		case 'd':
			dflg++;
			continue;

		case 'g':
			gflg++;
			continue;

		case 'l':
			lflg++;
			statreq++;
			continue;

		case 'r':
			rflg = -1;
			continue;

		case 't':
			tflg++;
			statreq++;
			continue;

		case 'u':
			uflg++;
			continue;

		case 'i':
			iflg++;
			continue;

		case 'f':
			fflg++;
			continue;

		default:
			continue;
		}
		argc--;
	}

Шах и мат :)

/etc/portage/package.use/-python
/etc/portage/package.use/-gconf
/home/andor/dev/alexott-emacs-configs/snippets/text-mode/markdown-mode/-
/var/db/pkg/app-admin/-MERGING-eselect-ecj-0.7
/home/andor/.dvdcss/-154bcd00154d6200-0000000000
/home/andor/.dvdcss/-c46e8700c56e7400-0000000000
/home/andor/Games/.starcraft2/drive_c/users/andor/My Documents/StarCraft II/Accounts/1918021/2-S2-2-360568/Replays/Multiplayer/-xX- HeroesVSHybrid -Xx-.SC2Replay

кста фишка(была -сейчас это общее место) unix'а - шелл это отдельное от ядра(которое системные вызовы обрабатывает) приложение так что пили свой шелл с удобным (ортогональным логичным - короче на твой вкус) - ежель вещь будет удобная то люди потянутся

ps. возможно такие шеллы уже пилятся .