-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to read messages from localized versions of utilities. #317
base: master
Are you sure you want to change the base?
Conversation
If the utilities output localized messages, these messages are unreadable. For example, instead ERROR: getBinaryRPaths: "objdump: 'not_exists_file': Нет такого файла\n" we see ERROR: getBinaryRPaths: "objdump: 'not_exists_file': \xD0\x9D\xD0\xB5\xD1\x82 \xD1\x82\xD0\xB0\xD0\xBA\xD0\xBE\xD0\xB3\xD0\xBE \xD1\x84\xD0\xB0\xD0\xB9\xD0\xBB\xD0\xB0\n"
We've already taken all STDERR in line: if (strip.readAllStandardError().contains("Not enough room for program headers")) So, the next line will not print the error message LogError() << "Error stripping" << QFileInfo(resolvedPath).completeBaseName() << ":" << QString::fromLocal8Bit(strip.readAllStandardError());
Thanks @SokoloffA good catch. However I think we should use a different solution: Instead of trying to parse non-English output, we should set environment variables so that the utilities called by Do the equivalent of the following bash commands:
Can you please verify that this works for you, and potentially implement this in your PR (possibly in addition to the UTF8 stuff you added)? Thank you very much. |
Just changing the locale is not enough.
Most Linux systems use UTF-8, so LANG=en_US.utf8 gives a better result:
But the error messages are still unreadable:
So we should to use QString::fromLocal8Bit in any case. |
Why is "Linux" always so complicated... how can we set everything to International English? |
I have a fashionable solution. We have to send the text to the google-translate :) Seriously, as I understand you're worried about the code like:
We can set the locale for QProcess, but in any case the user may have non English letters in the file names. So we hould to set the locale for process and use fromLocal8Bit too. |
The obvious approach is to set |
That's what I meant to do, only to find that in typical "Linux" fashion there is not one but multiple similarly-named variables to set the language... and seemingly picked the wrong example. So @SokoloffA can you confirm that it works with @TheAssassin's solution? Thanks. |
You can easily test which variable works for which tool: just |
Strange result. In my distribution $LS_ALL does not overwrite the $LANGUAGE variable.
But when I added the string ldd.setEnvironment(QStringList() << "LC_ALL=en_US.UTF-8"); to the code, the program print a message in English.
In any case, we cannot use the "C" locale. If program use the "C" locale, I cannot use Russian filenames.
|
The issue with that is that |
I don't really understand why this PR resulted in a locale discussion. The issue seems to be about supporting file names with special characters, which as per results shown by @SokoloffA clearly can't be solved by forcing a C locale. Instead, the proposed patch seems to be to be the right solution. Using Edit: An exception to this is when standard output/error is passed on to |
Makes sense, sorry if I got it wrong earlier. |
Fix: Unable to read messages from localized versions of utilities.
If the utilities output localized messages, these messages are unreadable. For example, instead
we see
Fix: Empty error message.
We've already taken all STDERR in line:
So, the next line will not print the error message