Your message dated Tue, 24 Feb 2009 15:10:56 +0100 (CET)
with message-id <[email protected]>
and subject line Re: Bug#516895: gettext: wrong parameter handling?
has caused the Debian Bug report #516895,
regarding gettext: wrong parameter handling?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
516895: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516895
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gettext
Version: 0.17
Severity: minor
Hi,
I have the following C++ source file:
$ cat test.cc
#include <iostream>
#define _(text) text
int main()
{
std::cout << _("Hi, this is a string") << "\n";
return 0;
}
The paramater handling of option -k causes some problems for me:
According to xgettext --help:
-k, --keyword[=WORD] additional keyword to be looked for (without
WORD means not to use default keywords)
$ xgettext -k=_ -o test.po test.cc; cat test.po
cat: test.po: No such file or directory
Using
$ xgettext --keyword=_ -o test.po test.cc
a proper PO file is created as "_" is recognized as keyword.
Now I wonder, does the short option -k accept parameters or not?
If not shouldn't it complain about "=_"?
I also tried
$ xgettext -k _ -o test.po test.cc; cat test.po
xgettext: xgettext cannot work without keywords to look for
I haven't looked at the source but I think GNU command line parsing
supports also options to short params. See e.g. the examples
% testopt -c foo
aflag = 0, bflag = 0, cvalue = foo
% testopt -cfoo
aflag = 0, bflag = 0, cvalue = foo
in
http://www.gnu.org/software/libtool/manual/libc/Example-of-Getopt.html#Example-of-Getopt
Yep, it is only a minor issue but it took me 5 minutes until I found that
I have to use the long form of the option. I played with --c++ and further
options first because I assumed another option was missing.
Jens
--- End Message ---
--- Begin Message ---
On Tue, 24 Feb 2009, Jens Seidel wrote:
> On Tue, Feb 24, 2009 at 11:31:39AM +0100, Jens Seidel wrote:
> > The paramater handling of option -k causes some problems for me:
> >
> > According to xgettext --help:
> >
> > -k, --keyword[=WORD] additional keyword to be looked for (without
> > WORD means not to use default keywords)
> >
> > $ xgettext -k=_ -o test.po test.cc; cat test.po
> > cat: test.po: No such file or directory
> >
> > I also tried
> > $ xgettext -k _ -o test.po test.cc; cat test.po
> > xgettext: xgettext cannot work without keywords to look for
>
> Ah, according to GNU getopt routines
> (http://puszcza.gnu.org.ua/software/mailfromd/manual/html_node/getopt.html):
>
> <quote>
> Options may have arguments. The argument to a short option is supplied
> immediately after the option character, or as the next word in command line.
> E.g., if option ÿÿ-fÿÿ takes a mandatory argument, then it may be given either
> as ÿÿ-fargÿÿ or as ÿÿ-f argÿÿ. The argument to a long option is either given
> immediately after it and separated from the option name by an equals sign
> (as ÿÿ--file=argÿÿ), or is given as the next word in the command line (e.g.
> ÿÿ--file argÿÿ).
> If the option argument is optional, i.e. it may not necessarily be given,
> then only the first form is allowed (i.e. either ÿÿ-fargÿÿ or ÿÿ--file=argÿÿ.
> </quote>
>
> OK, this last sentence seems to confirm gettext's behaviour. I nevertheless
> failed to find this in the current glibc documentation or somewhere on
> www.gnu.org.
>
> Let's close this bug?
Yes, as it does not seem to be a gettext-related problem strictly speaking.
Or, if you prefer, you can reopen and reassign to whatever package
contains the gnu coding standards, or glibc documentation.
Thanks.
--- End Message ---
