#240 lircd: Use of optional optargs -> problems on non-glibc platforms

[mycroft2k]

i have compiled lirc version 0.9.2-0.9.5 all have the same problems (Raspbian Jessie Lite Kernel 4.4.21)
when i start lirc with listen option

root@raspberrypi:/# lircd -l10.10.2.77:111
lircd: bad port number "111Uùv"

root@raspberrypi:/# lircd -l0.0.0.0:8765
lircd: bad port number "8765 5úv"

when i start lirc with 'lircd -l0.0.0.0:111' is listen on port 111 and is working (port 1 - 999)

start lircd with 'lircd -l0.0.0.0:00008765' will lircd listen on port 8765 an works

can you fix the problem?

[Alec Leamas]

Hi!

hm... argument parsing problem? Can you first try with more recent source, lirc as as of now at 0.9.4c. Even if I doubt that an update fixes the problem, we need a fresh version in order to patch.

Also, please enable at least debug logging (-Ddebug), attach the lircd logs and report back.

[mycroft2k]

with -Ddebug only this two lines i see in the logs

Oct 30 15:30:33 raspberrypi lircd-0.9.4c[1942]: Info: lircd: Opening log, level: Info
Oct 30 15:30:33 raspberrypi lircd-0.9.4c[1942]: Info: Initial device: auto

[Alec Leamas]

Some things:

• Do you still have the "bad port number" messages when using -l option?
• That logging is broken. Are you using syslog? in that case the syslog config might hide messages with prio < info in this case. Walk-around using the --logfile option using a regular file for now.
• If you still have have problems with the -l option, use LIRC_DEBUG_OPTIONS=1 lircd -l ... to get some extra debugging while parsing options.
• Note that all options could be set in the lirc_options.conf file.

Welcome back!

EDIT: Added more things

[mycroft2k]

lirc_options.conf set listen to 0.0.0.0:8670 put lircd starts with port 8765

root@raspberrypi:/etc/lirc# LIRC_DEBUG_OPTIONS=1 lircd
Dumping parsed option values:
[lircd]=UNDEF
[lircd:nodaemon]=[False]
[lircd:driver]=[default]
[lircd:device]=[/dev/lirc0]
[lircd:output]=[/var/run/lirc/lircd]
[lircd:pidfile]=[/var/run/lirc/lircd.pid]
[lircd:plugindir]=[/usr/lib/lirc/plugins]
[lircd:permission]=[666]
[lircd:allow-simulate]=[No]
[lircd:repeat-max]=[600]
[lircd:listen]=[0.0.0.0:8670]
[lircmd]=UNDEF
[lircmd:uinput]=[False]
[lircmd:nodaemon]=[False]
[lircd:connect]=UNDEF
[lircd:logfile]=[syslog]
[lircd:debug]=[6]
[lircd:release]=UNDEF
[lircd:dynamic-codes]=[False]
[lircd:uinput]=[False]
[lircd:configfile]=[/etc/lirc/lircd.conf]
[lircd:driver-options]=[]
[lircd:effective-user]=[]

i have compiled on other machine Debian 8.0 32bit --> lircd: bad port number "111Uùv"
on Debian 8.0 64bit --> lircd with listen port is working

[Alec Leamas]

Sorry for not following up. If you are still on 0.9.2: Could you please try the current 0.9.4c version instead? IIRC, there was some command line parsing bugs which were resolved by post-release patches. Anyway, there is no need to spend time on the outdated 0.9l,2 these days.

[Felix Schmidt]

It looks like a getopt_long() implementation that does not support optional parameters. I have the same issue with uClibc (in 0.9.4c).

Using --listen= instead works.

"Fixing" this would make the command line incompatible (e.g. trying to make -l without parameter and adding another one for the host:port).

See http://stackoverflow.com/questions/19604413/getopt-optional-arguments:

POSIX.1-2008, section 12.2, "Utility Syntax Guidelines", explicitly forbids this feature:

Guideline 7: Option-arguments should not be optional.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

[Alec Leamas]

Yes, this is a 15-20 year old syntax. Question is if problem is big enough to motivate a break. Re-phrasing issue.

Using --listen= instead works.

I presume --listen "" also works then? If so, I tend to think we should live with this for now, besides documenting how it works on non-glibc platforms. After all, using lirc_options.conf (the primary usecase), this is a non-issue.

That is not to say I'm sure.

[Alec Leamas]

Documentation fix in [b148c3] (master). Time will tell if more work is needed w this issue.

[Felix Schmidt]

Sorry, i didn't test thoroughly.
No, listen alone did not work (with the patch from #240). This fixes this as well:
https://paste.fedoraproject.org/511529/

A NULL string was assigned via options_set_opt() if no parameter is given, the previous patch did not take care of this.

[Alec Leamas]

Mid-air collision... I spotted that and it should be fixed in current master. Could you please verify.

[Felix Schmidt]

Forget it, i see you already took care of this in the latest commit ..

[Felix Schmidt]

tested, works

[Alec Leamas]

Actually, this is still buggy. However, my feeling is that it's not bad enough to motivate a change of the syntax.

Thoughts? Can we close thiis, basically as wontfix?

[Felix Schmidt]

I think there are two issues (and jumping between different tasks got me a little bit confused):
1. The one reported here originally ("bad port number"). This is fixed with #249
2. -l parameter not accepting an argument. Just leave it and use --listen insted IMHO (This is likely just a behaviour in my environment, initially i wrongly thought it would be related to this issue).

[Alec Leamas]

We have actually re-phrased this issue to cover the -l issue. Which we wont solve, just document.

Thanks for all help, reporting, patching... Merry Xmas!