GNU gettext - Bugs: bug #58356, xgettext does not reject bogus...
You are not allowed to post comments on this tracker with your current authentication level.
bug #58356: xgettext does not reject bogus file names when emitting file references
Submitter: | Guido Flohr <gflohr> | ||
Submitted: | Tue 12 May 2020 10:53:19 AM UTC | ||
Category: | Programmer tools | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Tue 12 May 2020 03:16:18 PM UTC, comment #2: |
Guido Flohr <gflohr>![]() |
Tue 12 May 2020 03:07:33 PM UTC, comment #1:
|
Bruno Haible <haible>![]() |
Tue 12 May 2020 10:53:19 AM UTC, original submission:
I have a C source file "two\nlines.c" (with an embedded newline character in the name):
$ cat 'two
#: /tmp/two
Similarly, commas should be escaped, so that a source file "foo.c:42, bar.c" would not result in two references.
It is, of course, not a valuable feature to be able to process filenames with embedded commas or newlines. But the current state is that xgettext produces a file without errors or warnings that msgfmt cannot parse.
A simple solution would be to just throw a fatal error for such cases. |
Guido Flohr <gflohr>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-05-12 | haible | Category | None | ![]() |
Programmer tools |
Summary | xgettext does not escape special characters in comments | ![]() |
xgettext does not reject bogus file names when emitting file references |
My bad ... references are separated by spaces not by commas.
But that means that filenames containing spaces should be rejected as well. Strictly speaking, it would be sufficient to reject filenames that match the regex /:[0-9]+ ./ but probably most PO editors will simply split at a space and that guard would not be sufficient for them.