I'm using bash-2.0.5b-r5, LC_ALL=fr_FR@euro (yes I'm french :) and CONSOLEFONT="lat9w-16". When I "cd some_dir_that_doesn't_exist", I get the following error message : "-bash: cd: some_dir_that_doesn't_exist: Aucun fichier ou r?pertoire de ce type" It seems that the stressed letter "
I'm using bash-2.0.5b-r5, LC_ALL=fr_FR@euro (yes I'm french :) and CONSOLEFONT="lat9w-16". When I "cd some_dir_that_doesn't_exist", I get the following error message : "-bash: cd: some_dir_that_doesn't_exist: Aucun fichier ou r?pertoire de ce type" It seems that the stressed letter "é" is shown as a "?", and this only happens in console mode (I don't see this behaviour under X and with various terms), OR when sshing under X on a remote host. With others shell like sh or csh it won't happen. Neither with 'ls', 'du' or others. This make me think it is a bash bug.
it's probably your console font considering you say it only happens while in console ... why not try using a different console font ?
I don't think it comes from the font, because : I'm in console, I do a "mkdir
I don't think it comes from the font, because : I'm in console, I do a "mkdir ééé" followed by a "ls", and I really see "ééé" and no "???". I mean the font I'm using (lat9w-16) *knows* how to display stressed letters. I think bash isn't using the right encoding for errors messages of the "cd" command.
it's gone from the official mirror, i added it to distfiles-local
i get the same behaviour with -r7.
this error seems to happen the first time i log in on the console, but if i run a new shell, i don't get the error, see : ~$ cd foo -bash: cd: foo: Aucun fichier ou r?pertoire de ce type ~$ bash ~$ cd foo bash: cd: foo: Aucun fichier ou r
this error seems to happen the first time i log in on the console, but if i run a new shell, i don't get the error, see : ~$ cd foo -bash: cd: foo: Aucun fichier ou r?pertoire de ce type ~$ bash ~$ cd foo bash: cd: foo: Aucun fichier ou répertoire de ce type ~$ exit exit ~$ cd foo -bash: cd: foo: Aucun fichier ou r?pertoire de ce type ~$
I can reproduce this bug. I also see this if I ssh in from another box. If I ssh or login and run 'bash', I get the accent as expected.
Here's what I've determined so far: * ksh does not have this problem * It's not just fr_FR that has the bugs, pt_GB shows similar results I hunted down the code that displays that error and added a few debug strings to it. It's in builtins/cd.def, and it's the last call to builtin_error() in function cd_builtin(). If I hard-code an accented character into the error string it will display correctly. It seems to be the call to strerror() that's causing problems. The strerror() function comes from glibc, and it's defined in the header <strings.h>. The implementation starts off in the file string/strerror.c , and the message is handled by __strerror_r(). This in turn is in sysdeps/mach/_strerror.c , which makes me never want to look at another .c file in my life... The key line is the final return in the function: return (char *) _(_sys_errlist_internal[errnum]); Replacing this with: return "~~test>
Here's what I've determined so far: * ksh does not have this problem * It's not just fr_FR that has the bugs, pt_GB shows similar results I hunted down the code that displays that error and added a few debug strings to it. It's in builtins/cd.def, and it's the last call to builtin_error() in function cd_builtin(). If I hard-code an accented character into the error string it will display correctly. It seems to be the call to strerror() that's causing problems. The strerror() function comes from glibc, and it's defined in the header <strings.h>. The implementation starts off in the file string/strerror.c , and the message is handled by __strerror_r(). This in turn is in sysdeps/mach/_strerror.c , which makes me never want to look at another .c file in my life... The key line is the final return in the function: return (char *) _(_sys_errlist_internal[errnum]); Replacing this with: return "~~test>é<test~~"; Will display the accent correctly. So, I think something's wrong with either _() or _sys_errlist_internal. _() is a gettext thing, and _sys_errlist_internal appears to be just a list of messages to be passed to gettext. I don't speak C, however, so I could be wrong... BTW, running './asdf', where 'asdf' doesn't exist, will give the same error message, complete with duff accent. It's not just that message either. Running 'touch test && ./test' will give the error: "Permission non accord?e". Again, entering a subshell will temporarily fix the message. At this point, I'm not sure if glibc or gettext is to blame...
Oops, minor correction. For "sysdeps/mach/_strerror.c", read "sysdeps/generic/_strerror.c" (not sure where that mach came from...).
Az, wacha think?
I have a fix! Well, actually, I have a wierd ugly hack that prevents this behaviour. I don't understand it, but it works for me and I'd be interested in whether it fixes things for others. If LC_ALL is set in .bashrc, adding the following line immediately after the EXPORT will give correct accents: cd /fixforbug29665 >/dev/null 2>&1 Where /fixforbug29665 is some directory that doesn't exist. If LC_ALL is set in /etc/profile, adding the above line immediately after the EXPORT seems to work too. Some further notes, which may help anyone who's looking for the actual cause of the bug... * The redirect isn't necessary, but not having it may break scp and the like * If the redirect isn't there, the accent displays correctly * Adding in an echo or eval echo instead of the cd doesn't fix it * Adding in a different bash internal, such as ./fixtheaccentbug, will fix it * I can't find a french error message that doesn't contain an accent, so I can't be sure whether or not the error is only fixed if the output contains a dodgy character. I can test if someone can give me the relevant message... * Adding in 'cd ~' or anything else that produces no error doesn't fix it
NLS issue with bash ? There is a patch frm MDK here: http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/SPECS/bash/bash-2.05-i18n-0.5.patch?rev=1.1&content-type=text/plain but it does not apply, so I assume that some of the others are needed ...
I've tested this in bash-3.0, it's fixed there
