Bug 354171 - bogus locale handling: ENAMETOOLONG, environment strings in filenames
Summary: bogus locale handling: ENAMETOOLONG, environment strings in filenames
Alias: None
Product: Fedora
Classification: Fedora
Component: bash   
(Show other bugs)
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Roman Rakus
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-26 14:38 UTC by John Reiser
Modified: 2014-01-13 00:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-18 23:54:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace output showing dubious filenames (locale strings in filename) (13.66 KB, text/plain)
2007-10-29 19:35 UTC, John Reiser
no flags Details

Description John Reiser 2007-10-26 14:38:38 UTC
Description of problem: When setting up locale handling as part of shell
initialization, bash tries to open filenames that make no sense.  In particular,
one of the names gets ENAMETOOLONG, and several of them contain complete
"name=value" strings from the environment, and other filenames contain multiple
concatenated "name=value" strings.

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
1. strace -e trace=file bash -c date
Actual results:
O_RDONLY) = -1 ENAMETOOLONG (File name too long)
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/LC_CTYPE=en_US/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such
file or directory)
O_RDONLY) = -1 ENOENT (No such file or directory)
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/LC/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or
O_RDONLY) = -1 ENAMETOOLONG (File name too long)
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/LC_CTYPE=en_US/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No
such file or directory)
O_RDONLY) = -1 ENOENT (No such file or directory)
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/LC/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or
O_RDONLY) = -1 ENAMETOOLONG (File name too long)
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/LC_CTYPE=en_US/LC_TIME", O_RDONLY) = -1 ENOENT (No such
file or directory)
O_RDONLY) = -1 ENOENT (No such file or directory)
O_RDONLY) = -1 ENOENT (No such file or directory)

Expected results: no "garbage" in filenames

Additional info:

Comment 1 Tomas Janousek 2007-10-29 18:15:01 UTC
I wasn't able to reproduce this. Could you attach full output of "strace -f bash
-c date", please?

Comment 2 John Reiser 2007-10-29 19:34:01 UTC
I cannot reproduce it today, either.

Attached is strace output (14KB excerpt) where I first noticed it, running
strace on anaconda install from DVD.  That output is huge (1GB), so I reproduced
the problem using 'date'.  Perhaps the environment was bad already upon entry to

Comment 3 John Reiser 2007-10-29 19:35:15 UTC
Created attachment 242331 [details]
strace output showing dubious filenames (locale strings in filename)

from strace of anaconda during install from DVD

Comment 4 Tomas Janousek 2007-10-29 20:13:43 UTC
That's strange. Probably not a bash bug though. What snapshot is that?

Comment 5 John Reiser 2007-10-29 20:21:13 UTC
I began testing anaconda installs from DVD and CDs last week, and first noticed
this problem on Thu.Oct.25.  (I create my own install media using pungi, with
source from rawhide via mirrors.)   After composing three or four DVD and
installing them, I tried and was able to re-create the problem just using "bash
-c date".  But not today.

Comment 6 Tomas Janousek 2007-10-29 20:42:39 UTC
I see.

Please, check versions of glibc and bash on the DVD that works and on the DVD
that does not. It may be a bug in one of those which have been fixed already.
And check, whether tomorrow's compose works. Thanks.

Comment 7 Enrico Scholz 2008-05-17 23:56:35 UTC
Seems to be triggered when LANG + LC_COLLATE are set to different values:

| $ env -i LANG=de_DE.utf-8 LC_COLLATE=C /usr/bin/strace /bin/bash -c false
O_RDONLY) = -1 ENAMETOOLONG (File name too long)
O_RDONLY) = -1 ENOENT (No such file or directory)

Happens both on F-9 and F-8


Comment 8 Roman Rakus 2008-06-02 17:45:33 UTC
It's enough to set LC_COLLATE=C.
The problem is in point, where we call setlocale(LC_ALL,""); for getting locale
and then we assign this value setlocale(LC_CTYPE,getted_value);
hence changing component to glibc. Probably it's issue of setlocale().

Comment 9 Ulrich Drepper 2008-07-02 15:03:12 UTC
(In reply to comment #8)
> It's enough to set LC_COLLATE=C.
> The problem is in point, where we call setlocale(LC_ALL,""); for getting locale
> and then we assign this value setlocale(LC_CTYPE,getted_value);
> hence changing component to glibc. Probably it's issue of setlocale().

This is no glibc problem.  The value returned by setlocale() is only usable for
calls with the same category vlaue.  I.e., you can pass the return value of

   setlocale(LC_ALL, "")

only to other calls like

  setlocale(LC_ALL, str)

but not

  setlocale(LC_CTYPE, str).

If you want to get a value for LC_CTYPE then add an explicit

  setlocale(LC_CTYPE, NULL)

call after the successful

  setlocale(LC_ALL, "")


Reassigning back to bash.

Comment 10 Bug Zapper 2008-11-26 02:02:19 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Comment 11 Bug Zapper 2009-11-18 12:22:32 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 12 John Reiser 2009-11-18 23:54:18 UTC
Bug persists in (up-to-date) bash-3.2-30.fc10.i386; reproduced via the example in Comment #7.

Bug apparently was fixed in bash-4.0-8.fc11.  At least, I cannot reproduce it there.

Note You need to log in before you can comment on or make changes to this bug.