Re: German message error "Konnte nicht geöffne t werden" printed to stdout instead of s tderr

[Alexander Kriegisch]

Some more information: I found the relevant string in

/usr/share/locale-langpack/de/LC_MESSAGES/make.mo

which is part of Debian package language-pack-de-base, currently installed on 
my Ubuntu Oneiric in version 1:11.10+20111006.

I have no idea if I should address you or the mentioned package maintainer 
(Language pack maintainers <address@hidden>). At least I could pinpoint the 
problem which might also exist for other strings and other languages.


Alexander Kriegisch, 18.10.2011 08:28:
> Thanks for answering, Paul.
> 
> Actually, the context is as follows: I am logging the output of
> 
> make --print-data-base --question
> 
> in order to write my hierarchical structure of included makefiles into one, 
> big makefile. It is even possible to re-run make upon this big makefile with 
> identical results after removing some variable definitions like MAKEFLAGS, 
> MFLAGS, MAKECMDGOALS. This helps me to profile the impact of reading many 
> (and I mean many) small include files as opposed to just loading and parsing 
> one big makefile. The difference in our project is a significant 6.5 seconds 
> or so in case the hard disk read cache is empty, BTW. We will not convert 
> everything to one makefile, but wanted to know where we lose time.
> 
> Anyway, the relevant part of the captured output looks like this:
> 
> English:
> 
>> # Pattern-specific Variable Values
>>
>> # No pattern-specific variable values.
>>
>> # Directories
>>
>> (...)
>> # make/pciutils (device 29954, inode 750349): 5 files, 17 impossibilities.
>> # make/inotify-tools/SCCS: could not be stat'd.
>> # . (device 29954, inode 740347): 162 files, 68 impossibilities.
>> # make/libs/libavmhmac/RCS: could not be stat'd.
>> # make/Config.in (device 29954, inode 753850): could not be opened.
> 
> German:
> 
>> # Pattern-specific Variable Values
>>
>> # Keine musterspezifischen Variablenwerte.
>>
>> # Verzeichnisse
>>
>> (...)
>> # make/pciutils (Gerät 29954, I-Knoten (inode) 750349): 5 Dateien, 17 
>> Unmöglichkeiten.
>> # make/inotify-tools/SCCS: Konnte den Status nicht feststellen.
>> # . (Gerät 29954, I-Knoten (inode) 740347): 161 Dateien, 51 Unmöglichkeiten.
>> # make/libs/libavmhmac/RCS: Konnte den Status nicht feststellen.
>> # make/Config.in (Gerät 29954, I-Knoten (inode) 753850):
>> Konnte nicht geöffnet werden.
> 
> Please check out the last line. The German message is not just a translation 
> of the English one, but contains an additional line break. I just noticed 
> because when I was cleaning the log from comment lines, this one was a 
> leftover which could not be parsed when re-running make upon the big makefile 
> (=log).
> 
> So the fix seems obvious: remove the additional line break from the German 
> message to get it in line with the original, English output.
> 
> Regards
> --
> Alexander Kriegisch
> 
> 
> Paul Smith, 17.10.2011 14:22:
>> On Mon, 2011-10-17 at 12:58 +0200, Alexander Kriegisch wrote:
>>> I am using GNU make 3.81 on Ubuntu oneiric (11.10). I noticed that the
>>> German error message "Konnte nicht geöffnet werden." is sometimes listed
>>> in my output, even if I redirect stderr to /dev/null. So obviously it
>>> goes to stdout. This happens for address@hidden, but not for
>>> LC_ALL=C. So maybe it is a language-specific bug or the English message
>>> equals "" or something. Please check and fix this problem.
>>>
>>> I would be happy if you would answer to this inquiry CC to my e-mail
>>> address because I am not subscribed to this list. Thanks.
>>
>> Hi Alexander.  Google translate shows me that this message means "Could
>> not be opened".
>>
>> I'm not sure what would show a message like that in GNU make.  My
>> suspicion, personally, is that this message is not coming from GNU make
>> at all but rather it's being printed by a program that GNU make is
>> invoking.
>>
>> I would need to see the context including the full text of the error
>> message to know for sure.
>>
>> In any event, GNU make's i18n/l10n implementation never, ever changes
>> anything like whether messages are printed to stdout or stderr based on
>> any of the LC_* values.  The only differences in behavior based on these
>> settings are in the output that is printed.
>>