Комментарии 34
Вы бы добавили примеров, а то просто текст плохо воспринимается.
Вот, набросал по вашему описанию pastie.org/428758
Кому интересно, компилить и пускать так:
Вот, набросал по вашему описанию pastie.org/428758
Кому интересно, компилить и пускать так:
$ gcc opt.c -o opt $ sudo chmod +x opt $ ./opt -a 2 -b 5 -o '*' 2 * 5 = 10
sudo chmod +x opt
ЩИТО? зачем здесь нужно sudo?
и с каких пор gcc стал создавать файлы без права на исполнение?
ЩИТО? зачем здесь нужно sudo?
и с каких пор gcc стал создавать файлы без права на исполнение?
добавил Ваш пример в статью, спасибо.
в примере ошибка:
printf(«example:\n»);
printf(" $ opts -a 323 -b 23 -o '-'\n");
printf(" a + b = 300\n");
printf(«example:\n»);
printf(" $ opts -a 323 -b 23 -o '-'\n");
printf(" a + b = 300\n");
Вот так то же самое делается с помощью boost::program_options.
Запуск без параметров:
Запуск без параметров:
Usage: -a [ --first-operand ] arg (=0) First operand -b [ --second-operand ] arg (=0) Second operand -o [ --operation ] arg (=+) Operation
Да, без примера как-то не очень
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <getopt.h>
void usage(char *name)
{
printf("usage: %s\n \
\t-h this message\n \
\t-c [config file]\n \
\t--help this message\n \
\t--config=config_file\n", name);
return;
}
int main (int argc, char *argv[])
{
int c;
while (1){
static struct option long_opt[] = {
{"help", 0, 0, 'h'},
{"config", 1, 0, 'c'},
{0,0,0,0}
};
int optIdx;
if((c = getopt_long(argc, argv, "c:h", long_opt, &optIdx)) == -1)
break;
switch( c ){
case 'h':
usage(argv[0]);
return(-1);
case 'c':
printf("option 'c' selected, filename: %s\n", optarg);
return(1);
default:
usage(argv[0]);
return(-1);
}
}
return(0);
}
* This source code was highlighted with Source Code Highlighter.
Если мы пишем на С++, а не лишь на С, то отличное средство предоставляет Boost.Program Options
в данной статье речь именно о С.
Да и например тащить для небольшой консольной утилитки за собой буст, это не совсем верно.
Хотя для крупных приложений на С++, такой вариант вполне приемлем.
Да и например тащить для небольшой консольной утилитки за собой буст, это не совсем верно.
Хотя для крупных приложений на С++, такой вариант вполне приемлем.
В данной статье негде не написано что речь идет именно о С :) Хотя нам с вами это очевидно, это все же не где не коснтатировано…
Утилитке уж надобыть совсем не большой что бы изобретать неболшой велосипед)
Boost он не для больших продуктов, он для уменьшения безпослезного рукоделья, но это лишь ИМХО
Утилитке уж надобыть совсем не большой что бы изобретать неболшой велосипед)
Boost он не для больших продуктов, он для уменьшения безпослезного рукоделья, но это лишь ИМХО
Да, Вы правы, конкретно, нигде не указано что это С, т.к. данный код будет компилироваться и в С++.
Это не велосипед, это вообще-то функции рекомендуемые к использованию POSIX и GNU.
P. S. Холиворить я не в коем случае не буду, как говориться, каждому свое, Ваше мнение вполне имеет право существовать, ведь в этом и прелесть языков подобных С/С++, где каждый может сделать что-то, именно так, как этого хочет он.
Это не велосипед, это вообще-то функции рекомендуемые к использованию POSIX и GNU.
P. S. Холиворить я не в коем случае не буду, как говориться, каждому свое, Ваше мнение вполне имеет право существовать, ведь в этом и прелесть языков подобных С/С++, где каждый может сделать что-то, именно так, как этого хочет он.
Там не тащится весь буст.
А что, разбирать опции командной строки нужно только в небольших консольных утилитах? Во вступительном слове мне возражали против буста с тем же самым аргументом. Такое впечатление, что всё, что написано под *NIX — это небольшие консольные утилиты, при том непременно на чистом С, без С++ и прочей «ереси».
Хотелось бы прочитать что-то о нормальном подключении программе конфиг-файлов, которые читались бы удобно и были более-менее НЕстрогими:
var0=arg1
var2 = ar
var = «string»
varrri0 = 1
А то думаю самостоятельно конфиг файлы, как и опции уже давно никто не парсит
var0=arg1
var2 = ar
var = «string»
varrri0 = 1
А то думаю самостоятельно конфиг файлы, как и опции уже давно никто не парсит
Я имел ввиду: любое количество пробелов, табы, комментарии с помощью диезов и т.д.
ну насчет нестрогих, Вы, конечно, зря. Зачем усиливать мировую энтропию?
А по поводу конфигов, есть же специализированные языки XML, YAML и др. специально созданные и заточенные под использование в качестве файлов конфигурации, существует множество библиотек под множество языков программирования, которые без труда позволяют разобрать эти конфиги.
Самостоятельно и опции и конфиги все еще парсят, поверьте.
А по поводу конфигов, есть же специализированные языки XML, YAML и др. специально созданные и заточенные под использование в качестве файлов конфигурации, существует множество библиотек под множество языков программирования, которые без труда позволяют разобрать эти конфиги.
Самостоятельно и опции и конфиги все еще парсят, поверьте.
Некоторые используют для этой цели Lua :)
Выполняют скрипт, в котором присваиваются значения переменным, а потом просто выбирают их значения.
Выполняют скрипт, в котором присваиваются значения переменным, а потом просто выбирают их значения.
Спасибо за статью) Краткая но информативная
А еще есть Boost ;-)
Когда то готовил подобную вещь.
А вообще есть ещё библиотека popt, очень мощный инструмент для разбора командной строки. Возможностей у неё больше чем у getopt().
А вообще есть ещё библиотека popt, очень мощный инструмент для разбора командной строки. Возможностей у неё больше чем у getopt().
Спасибо за статью. Очень интересно.
Давайте уже закопаем Си наконец, а?
Поймите меня правильно, но Си нужен только *в нишах*. Ниши Си хорошо известны. Давайте не будем уподобляться opensource-сообществу в использовании инструментов не по назначению.
Очень хочется указать на хотя бы std.getopt из D2.0. Даже там не приходится писать такое большое количество глупого кода, который, к тому же, не проверяет ввод пользователя.
Что будет, если запустить программу-пример с одним параметром -o '-'? А если мы пишем что-нибудь более серьезное, например, небольшой вебсервер? Сколько граблей будет там?
Как видите, Си — для людей с железными яйцами. Используйте только в крайних ситуациях.
Поймите меня правильно, но Си нужен только *в нишах*. Ниши Си хорошо известны. Давайте не будем уподобляться opensource-сообществу в использовании инструментов не по назначению.
Очень хочется указать на хотя бы std.getopt из D2.0. Даже там не приходится писать такое большое количество глупого кода, который, к тому же, не проверяет ввод пользователя.
Что будет, если запустить программу-пример с одним параметром -o '-'? А если мы пишем что-нибудь более серьезное, например, небольшой вебсервер? Сколько граблей будет там?
Как видите, Си — для людей с железными яйцами. Используйте только в крайних ситуациях.
А может кто-то хочет армировать себе яйца? Давайте не будем их лишать этого :) Здесь только даются азы, никто не заставляет людей пользоваться си в обязательном порядке.
Я с вами отчасти согласен. На текущий момент Си предназначен исключительно для системного программирования. Большая часть десктопных приложений создаётся как минимум на C++. Enterprise системы больше на C# или Java.
Форум изначально хотели вести о "системном программировании под *nix", а в названии решили отразить просто «программирование под *nix». Само по себе «программирование под *nix» без привязки к языку, это какая-то очень размытая тема. На C++ я стараюсь использовать кросс-платформенные библиотеки (stl, boost и т.д.), а Java и C# платформонезависимы по своей природе. В итоге, никаких различий в разработке, которые тут собираются обсуждать просто нет. Серьёзные различия возникают при разработке системных приложений на Си.
P.S. Небольшой, но быстрый вэб-сервер я бы как раз писал на C. А большой и функциональный вэб-сервер, наверное, всё же на C++. А вэб-сервер, который умеет пересобирать KDE под FreeBSD наверное на Java. И opensource-сообщество тут ни причём. Средство реализации определяет задача, но никак не наоборот.
Форум изначально хотели вести о "системном программировании под *nix", а в названии решили отразить просто «программирование под *nix». Само по себе «программирование под *nix» без привязки к языку, это какая-то очень размытая тема. На C++ я стараюсь использовать кросс-платформенные библиотеки (stl, boost и т.д.), а Java и C# платформонезависимы по своей природе. В итоге, никаких различий в разработке, которые тут собираются обсуждать просто нет. Серьёзные различия возникают при разработке системных приложений на Си.
P.S. Небольшой, но быстрый вэб-сервер я бы как раз писал на C. А большой и функциональный вэб-сервер, наверное, всё же на C++. А вэб-сервер, который умеет пересобирать KDE под FreeBSD наверное на Java. И opensource-сообщество тут ни причём. Средство реализации определяет задача, но никак не наоборот.
> Серьёзные различия возникают при разработке системных приложений на Си.
Си довольно прост в том смысле, что приемы, доступные программисту, он предоставляет самый минимум. Поэтому тема скучная и не сильно нужная.
> Небольшой, но быстрый вэб-сервер я бы как раз писал на C.
А я бы взял Erlang. Он как раз для таких приложений и предназначен. Впрочем, наверное, где-нибудь я бы и использовал вставки Си.
> Средство реализации определяет задача, но никак не наоборот.
Ну вот Вы сами и показали, что не умеете выбирать.
Си довольно прост в том смысле, что приемы, доступные программисту, он предоставляет самый минимум. Поэтому тема скучная и не сильно нужная.
> Небольшой, но быстрый вэб-сервер я бы как раз писал на C.
А я бы взял Erlang. Он как раз для таких приложений и предназначен. Впрочем, наверное, где-нибудь я бы и использовал вставки Си.
> Средство реализации определяет задача, но никак не наоборот.
Ну вот Вы сами и показали, что не умеете выбирать.
Ещё есть GenGetopt, которая упрощает использование getopt_long. Мне она ещё понравилась тем, что при необходимости, для систем у которых в библиотеках нет такой функции (под Windows, например), позволяет добавить в генерируемый код реализацию getopt.
да, когда-то пришлось повозиться с гетопт
спасибо за статью.
спасибо за статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разбор опций командной строки в UNIX-подобных системах