Hmm, why did you change section name to 1? Zabbix manuals must be in 8, which is intended for system administration commands and utilities. Also, please explain what do you mean saying "hyphen used as minus sign", what does it fix?

Hi Alexei,

Thank you for your fantastic work and dedication.

In Debian, we allow non-privileged users to run utilities like zabbix_get and zabbix_sender. Strictly speaking those utilities doesn't have to be run as root but if you believe that it is worth restricting access to them then please ignore this suggestion.

Personally I believe from security prospective it make sense to use administrative account only when there is no way to do the job without it. Perhaps you might agree that even though the risk is little, there is no reason to run zabbix_get as root - therefore section name is 1.

Regarding "hyphen used as minus sign", the following page explain the (minor) problem:

http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html

To summarise, if "hyphen used as minus sign" it may not be possible to paste example from man page to command line.
Of course this is a very minor, pedantic issue.

Thank you.

Dmitry,

Are you saying that everything that is part of 'man 8' is intended for use by root only? Please give me a reference to relevant documentation.

Thanks for the second problem details, to be fixed.

Yes, in most cases.

According to Wikipedia

http://en.wikipedia.org/wiki/Man_page#Manual_sections

Section 1 is for general commands;
Section 8 is for System administration commands and daemons

So common sense would suggest to use Section 1 for everything which is neither daemon nor system administration command.

According to man(1) sections are as follows:

1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]

See also

http://manpages.debian.net/cgi-bin/man.cgi?query=man&apropos=0&sektion=0&manpath=Debian+testing+%28wheezy%29&format=html&locale=en

http://www.cyberciti.biz/faq/howto-use-linux-unix-man-pages/

http://unix.stackexchange.com/questions/3586/what-do-the-numbers-in-a-man-page-mean

Thank you.

the patch seems to escape one dash/minus only, i assume it would have to escape pretty much all of them... is that correct ?

will also use this dev branch for ZBX-2510

No need to escape all minuses - the issue affect only those preceded by space. That is exactly one case which I corrected with patch. Thank you.

what about cases like {"-p, --port", namely, the second '-' there ? it is preceded by space here. or does it affect single dash/minus that's preceded by space ?
my groff also seems to be patched for this, which makes testing more challenging

also, in that case https://github.com/ipython/ipython/pull/1014/files looks like overdoing it...

According to 'lintian' (a powerful Debian QA tool) the only one minus if affected.

Apparently those enclosed in double quotes are OK and as far as I can tell ipython is possibly overdoing it as I see no warnings for second minus character preceded by another minus and not by space.

I prefer minimalistic patches and it looks like it is only necessary to correct exactly one minus and not more.
Since lintian complains only about this particular minus probably there is no reason to change others until (if ever) someone will be able to reproduce the problem.

Cheers,
Dmitry.

i did some reading on this, and i'm still confused.

i can't find a single location saying that only single, white-space preceded dashes should be escaped. all manpages (groff, groff_char) do not make any distinction there. is lintian doing a correct check there ?

also, if i compare :

echo "-" | groff -Tutf8
echo "\-" | groff -Tutf8

the non-escaped version gives me plain dash on all distros i checked...

Yes lintian does correct check. I don't know how to reproduce the problem so I'm only relying on lintian to verify this.
I didn't think it is a real problem until I saw bug reports like this:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672111

I'm attaching corresponding README.Debian from groff-base - hopefully it will spread some light on the issue but IMHO it would be better just to escape one character and avoid spending more time on this.

Also lintian referencing the following man page:

http://manpages.debian.net/cgi-bin/man.cgi?query=groff_char&sektion=7

README.Debian as provided by groff-base

escaping one character would simply silence the check
i looked at all those manpages before, and i did not see a single instance stating that only single, white-space prefixed dashes would be treated like that. maybe it is possible to get a comment from the authors of http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html ?

even the description page of that check does not state that only those dashes should be escaped...

some brief discussion in #debian mostly concluded that, according to manpages, the check must be wrong.
maybe the answer lies in unpatched groff code examination...

"escaping one character would simply silence the check" is an unsubstantiated assumption. Sounds like excuse to me

Lintian checks are done very thoroughly. I have one man page where problem is manifested with lintian warning and indeed there are "[em]"s instead of dashes. If one minus is escaped neither lintian complaints nor I can see the problem in man page.

The fix itself is trivial and harmless. There is no reason to delay it even if you don't know how lintian works.

Also there is no reason to spend any more time discussing this - let's fix what we know.
Later if (ever) this problem will be reported again we can investigate if more effort is needed.

Please fix as proposed (for now), close this and move on to other issues.

Thank you.

Regards,
Dmitry.

Having said this I understand it is indeed possible that we're experiencing false-positive lintian warning.
However if we're not too sure, I would consider applying the fix because it is harmless and by applying it we will get rig of this confusion.

Thank you.

potential problem with lintian check reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729593

This issue is being fixed as part of solving ZBX-8391.

Available in development branch svn://svn.zabbix.com/branches/dev/ZBX-8391 .

I don't see any manpage changes there.

After SVN checkout, e.g.
svn co svn://svn.zabbix.com/branches/dev/ZBX-8391 ZBX-8391-test
the changed man pages are in
ZBX-8391-test/man

Sorry, I hadn't looked back far enough in the commits!

(1) Needs merge from upstream because of ZBXNEXT-101.

andris Merged in svn://svn.zabbix.com/branches/dev/ZBX-8391 rev.48896.

<dimir> Thanks, CLOSED

Successfully tested.

Fixed in version pre-2.5.0 r49008.

(2) changelog entry does not follow the guidelines (does not start with a verb in past tense)

andris RESOLVED in svn://svn.zabbix.com/trunk r49070.

<richlv> thanks, CLOSED