dhcpcd не верно обрабатывает длинный ключ `--clientid' для InfinyBand интерфейсов: #> dhcpcd --clientid 12:12:12:12:12:12:12:12:12 ib0 dhcpcd: `12:12:12:12:12:12:12:12:12' too long for an interface name (max=16) Но, в тоже самое время, для ключа `--clientid' есть сокращённый алиас `-I', его обработка идёт совсем иначе: #> dhcpcd -I 12:12:12:12:12:12:12:12:12 ib0 dhcpcd: dhcpcd will not work correctly unless run as root ib0: open `/var/run/dhcpcd-ib0.pid': Permission denied $ rpm -q dhcpcd dhcpcd-4.0.15-alt2 Ожидается что реакция на `-I' и на `--clientid' должна быть одинаковой.
Проблема в getopt_long(). Дело в том, что у --clientid аргумент заявлен как опциональный, а в этом случае getopt_long() не воспринимает пробел как разделитель между опцией и аргументом, надо обязательно ставить '=', т.е. dhcpcd --clientid=12:12:12:12:12:12:12:12:12 ib0 будет работать. Иначе это воспринимается как --clientid без аргумента, а '12:12:12:12:12:12:12:12:12' - как имя интерфейса. Честно говоря я не знаю "баг" это или "фича". В man'е никаких упоминаний об этом не вижу, так что скорее баг. Кстати, с короткими опциями в dhcpcd все иначе: там всегда требуется аргумент, в отличии от длинных. Но если сделать аргументы в коротких опциях тоже optional, то там тоже придется не использовать пробел, т.е. писать слитно -I12:12:12:12:12:12:12:12:12, т.к. getopt_long() в этом случае работает именно так.
Параметры -I и --clientid документированы как имеющие одинаковую семантику, однако по факту это не так. И вообще, фраза "if the clientid is an empty string" в dhcpcd(8) значит совсем не то же самое, что реализовано. Я думаю, что upstream должен определиться, как он хочет реализовать optional clientid, посредством "an option takes an optional argument", или с помощью "empty string argument", и привести в соответствии с этим решением и код, и документацию. --clientid=12:12:12:12:12:12:12:12:12 будет работать при любом из этих двух вариантов.
> Параметры -I и --clientid документированы как имеющие одинаковую семантику, > однако по факту это не так. И не только в этом случае, как я писал выше. У dhcpcd полно параметров с optional argument, но только в случае длинных опций. Если все их короткие аналоги сделать тоже с optional argument, то слишком многое сломается. Например etcnet использует '-h $HOSTNAME', это перестанет работать если -h, как и --hostname, будет с optional argument. Думаю лучше оставить как есть. > И вообще, фраза "if the clientid is an empty > string" в dhcpcd(8) значит совсем не то же самое, что реализовано. Я думаю, > что upstream должен определиться, как он хочет реализовать optional clientid, > посредством "an option takes an optional argument", или с помощью "empty string > argument", и привести в соответствии с этим решением и код, и документацию. Сейчас одинаково работают оба варианта (в случае длинной опции). Так что формально man не врет, просто там не упомянуто, что аргумент можно вообще опустить. Проблемы возникают именно из-за отличий работы getopt_long() в случаях required_argument и optional_argument. Почему эти отличия существуют вполне понятно, но от этого не легче. Можно сделать эти опции как required_argument и использовать только вариант с пустой строкой.
В общем, optional_argument так работает, т.е. так и задумано.