Bash – Why does the bash translation file not contain all error texts

bashlocale

I downloaded the latest version (4.4 for now) of Bash sources from GNU's site.

I opened French translation file (fr.po) from po directory and I searched for "permission denied". There were no results.

When I open terminal and run cd /var/log/apache2 I get the error: bash: cd: /var/log/apache2: Permission denied. So it IS a Bash error yet it's not included in mentioned file. Also, when I grep -rn . -e "denied" in the bash sources directory I only get 2 results, both of which are from file "COPYING".

Moreover, when I change Bash language with this command: export LC_ALL=fr_FR I get bash: cd: /var/log/apache2: Permission non accordée. Changing Bash language changes this error so it's another proof that this is indeed a Bash message.

Does anyone know why isn't this error included in the po file?

Best Answer

The string comes from strerror(3), which maps error numbers to messages. In this case, it's mapping EACCES. The strings (and their translations) are contained in your C library.

Related Solutions

Unzipping certain archives works on Windows but not on Linux

I've done some digging in the source code (unzip60 from Ubuntu raring, though I suspect older versions don't differ much). The error in question is internally called TruncNTSD and defined in extract.c:295. Most uses of this message, as expected, are in win32/win32.c and indeed refer to NTFS security data, however there's only one place in the code where you should ever get this error outside of a win32 system (since you reported seeing it on ubuntu).

The place in question (extract.c:2118) is in a function called TestExtraField. As Wikipedia explains:

.ZIP file format includes the extra field facility within file headers, which can be used to store extra data not defined by existing .ZIP specifications, and allow compliant archivers not recognizing the fields to safely skip the fields.

That's indeed what NT does to store security information. Importantly, the function printing the error comments

/* we know the regular compressed file data tested out OK, or else we
 * wouldn't be here ==> print filename if any extra-field errors found
 */

So if you can unzip the files themselves fine, it looks like this error is safe to ignore. Looking further, the only place outside of win32 code that raises this error (assuming it's not a horrible bug in unzip) is test_compr_eb:extract.c:2227, which from a glance at the code looks like it occurs when a zipped file has associated extra fields that are marked as compressed, but the field data has a length of 0 bytes.

How this comes about I don't know - perhaps the program creating the zip files does this by accident, perhaps the extra fields are filtered out somewhere by security software. In any case, it looks harmless and probably has nothing to do with NT security at all. In conclusion, if your files unzip fine, it's completely safe to ignore.

Bash – Exit bash when find gets to a folder with permission denied

find will set its return code to non-zero if it saw an error. So you can do:

if ! find ... 
then    echo had an error >&2
fi |
while ...

(I'm not sure what you want to do with the find output).

To collect all the error messages from find on stderr (file descriptor 2) you can redirect 2 to a file. Eg:

if ! find ... 2>/tmp/errors
then     zenity --error --text "$(</tmp/errors)"
fi |
while ...

Best Answer

Related Solutions

Unzipping certain archives works on Windows but not on Linux

Bash – Exit bash when find gets to a folder with permission denied

Related Question