And by that I managed to send my encrypted root password to the entire
world, together with hostname and IP number... Well, I guess it was
time to change it anyway.

Definetely :)

Seriously, have you tried to select Swedish as your
language at the login screen and hit 'set as default'
when the system asks?

i.e. before loggin in, select Language->Swedish in the
'Language' menu on the left.

What happens?

Thanks. I didn't think of looking there.

That partially solves the problem. That is, I get Swedish menus and
can type non-ASCII characters now. However, file names are not
displayed or matched correctly, and if I type a non-ASCII character
and delete it again it's only partially gone. That is, it seems I get
sv_SE.UTF-8. I'd like to have sv_SE (ISO 8859-1).

And in either case, choosing system default as language setting
obviously doesn't work correctly.

Hmmm.

Could you please create an attachment here with a screenshot
showing the 'file names not displayed correctly', so that we
all can have an idea?

Thanks.

Created attachment 101410 [details]
Screenshot displaying the gnome-terminal window

Certainly. Thank you for your effort.

I think it's pretty clear why it is this way: The filenames are in ISO
8859-1 and GNOME expects UTF-8. The problem is: How do I get it to be
sv_SE (system default) instead of sv_SE.UTF-8 or en_US? And why didn't
I get the system default to begin with?

(Damn it! I really hate these kinds of problems. After all the
troubles we had when moving from ISO 646-SE to ISO 8859-1 I thought it
was finally over. Now it seems we have to do it all over again. UTF-8
is a good idea for network protocols. I'm not sure it's such a good
idea internally in operating systems...)

Created attachment 101467 [details]
Attach 1 - language setup for user 'test'

Comment on attachment 101467 [details]
Attach 1 - language setup for user 'test'

Hello.

It seems the opposite as you think: the problem seems to be
that you selected sv_SE instead of sv_SE.UTF-8.

I did the following: on a FC2 fresh installation, on
which the system language is en_US.UTF-9, I created a
test user selefting for it Swedish as the language.

Now, this user logs as in this screenshot (see attach).

Created attachment 101468 [details]
Attach 2 - all chars are displyed correctly

Now, taker a look at this attach.

You can see that all national chars are displayed correctly, and
I can create a file with local chars in its name, and then list
it correctly.

Please do the following:

- edit /etc/sysconfig/i18n and set:
LANG="en_US.UTF-8"

- reboot your machine

This is to get rid of any localization at boot time. Your
computer should now boot in English, and use English as
the defualt language for users (BTW, setting system lang
to 'en_US.UTF-8' or even better to 'C' locale is something
I love. Users settings are different).

- as soon as you computer boots, log in as root (who should
have no particular setting) in a text console, and add an
user 'test'. Set its password.

- Immediately afterwards, log in into an X session, selecting
  'Swedish' as language. Make it default for user 'test'.
  (Language -> Swedish -> Make default? Yes)

- Go to preferences (yes I found them in swedish but don't ask
  me the name, it's something like Installningar :), keyboard,
  Layout, set the appropriate layout (this is just to make you
  input in swedish, in case your system keyboard is not properly
  set).

- You should be able to open a terminal, run rpm -qi kernel, and
  see the correct characters like in my screenshot above.

If not, please let me know.

If 'test' is correct, backup your data, remove your user, its home,
and add it again :)

Piero


P.S. There's a typo in comment 8 above: system LANG is
en_US.UTF-8 of course, not UTF-9 :)

That didn't help at all. Sorry.

Yes, of course I realize that I can set the system to use UTF-8, and
I'm perfectly well aware of how to do that. That's the default after
all. But the thing is: I don't want UTF-8. I want the system set to
ISO 8859-1 (sv_SE) as it is now, and I want to get GNOME to respect
that as well. Not ASCII. Not UTF-8.

The reason is not only that my hard drive is filled with names in ISO
8859-1, but I have a lot of CD:s which are as well. And mixing
character encodings would be a major pain in the aft region in this
case. Perhaps if I transfer it all to some new media in the future I
might consider going through all the work of moving to another
encoding, but that time is not now.

(If it is the intention of Red Hat and the Fedora crew to support only
UTF-8 in the future I guess it's time for me to look around for a new
distribution.)

And as you can see from anaconda-ks.cfg above, the system was set to
sv_SE.UTF-8 initially (choosing ISO 8859-1 at installation is not
possible). I explicitly changed it. So I don't just want the system
and GNOME to use the same settings. I want GNOME to use ISO 8859-1.
Perhaps I've not been clear about that. In that case I appologize.

(And in all my previous installations of Red Hat, GNOME has used the
system settings with no problems whatsoever.)

Does it work with bash (i.e. does this only happen with zsh), just as
a way to narrow it down?

ISO-8859-1 is supported if you set it explicitly, though the UI
encourages only UTF-8.

Ah. Yes, if I change the shell from zsh to bash everything works
perfectly.

So the question is why /etc/profile.d/lang.sh (sourced from
/etc/profile) doesn't get run or doesn't work with zsh...

Yeah. I spent a few hours reading documentation and looking around
(mainly in /etc/X11/) yesterday with no success. I'm certainly no
expert on what goes on when logging into GNOME though. Sourcing
lang.sh in Init or the *Session* directories under /etc/X11/gdm/
doesn't seem to do much good though. 

Well. As a very ugly, temporary fix changing the shell to bash and
using the following works at least:

as8-4-4:~% cat .bashrc
# .bashrc
 
if [ "$TERM" = "linux" -o "$TERM" = "xterm" ]; then
        exec zsh
fi
as8-4-4:~%

Interestingly enough, everything works fine with tcsh as well.

Created attachment 101509 [details]
A patch for /etc/zprofile which solves this bug.

Well. I've solved the problem. The solution is more or less given
above, but I guess it was to simple since I didn't come to think of it
earlier: /etc/profile simply doesn't get sourced anywhere, and thus
not /etc/profile.d/lang.sh either. I sure didn't expect that to turn
out to be the problem when I opened this bug. :-)

I suggest the attached patch to be applied and an updated package of
zsh released. The added lines have been included in /etc/zprofile in
zsh packages distributed with previous versions of Red Hat. It would
be interesting to know why they were removed.

(I've changed the component from gnome-session to zsh now as well.)

Created attachment 101511 [details]
A better version of the previous patch perhaps?

Well. Or this one, which seems more in line with how things are done in the
/etc files nowadays. Or maybe add parts of /etc/profile to /etc/zprofile. As
long as /etc/profile.d/lang.sh gets included in some way...

And while I'm at it:

It might also be a good idea to include the end of /etc/bashrc in
/etc/zshrc, since some of the files in /etc/profile.d/ (such as
colorls.sh) should be sourced in shells which are not login shells.

Hmmm, the current behaviour comes from bug 65509.
Btw this is a duplicate of bug 102187.

Looking back now, I start to think that indeed you're right
that /etc/zprofile is probably the right place to source profile.

By comment 22, you mean this:

    if [ "x$SHLVL" != "x1" ]; then # We're not a login shell
        for i in /etc/profile.d/*.sh; do
	    if [ -r "$i" ]; then
	        . $i
	    fi
	done
	unset i
    fi

presumably?

Should get fixed in 4.2.0-3.

Thank you for the report and for looking into this carefully.

*** This bug has been marked as a duplicate of 102187 ***

> Btw this is a duplicate of bug 102187.

Well. At the time, I didn't exactly think of searching for zsh related
topics.

Are you sure it's a good idea to change the summary for this one? If
another person encounters it as a GNOME-related language problem
he/she probably won't find it either.

> By comment 22, you mean this:
> 
>     if [ "x$SHLVL" != "x1" ]; then # We're not a login shell
>         for i in /etc/profile.d/*.sh; do
> 	    if [ -r "$i" ]; then
> 	        . $i
> 	    fi
> 	done
> 	unset i
>     fi
> 
> presumably?

Yes.

I'm not sure it's such a good idea to mix things which should be run
in login shells with things which should be run in all interactive
shells in /etc/profile.d/. But that's the way it's done for bash, so I
guess it should be for zsh as well. Sourcing it in zprofile only is
not enough, which I guess was the reason it was put in zshenv.

But sourcing /etc/profile.d/lang.sh should most definately not be done
in ~/.zshrc, considering what it does. That should be done in a system
file.

Putting the extra /etc/zshrc lines above in ~/.zshrc instead is an
option however, although I think it would be much better to have it in
the former (an option not availible in bash).

I've seen the bug is closed, sorry both for not being useful
(I didn't even think of zsh initialization being the problem)
and for leaving for a while w/out a warning, but it wasn't
expected.

Piero

Magnus, the sourcing of /etc/profile.d/*.sh is in zshrc now. :)

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

> Magnus, the sourcing of /etc/profile.d/*.sh is in zshrc now. :)

This is wrong. This will override user settings in ~/.zprofile. Please see zsh
man pages or consult the zsh mailing lists if in doubt but don't do this.
Something related is at Bug 225454.

/etc/profile should be sourced in /etc/zprofile ONLY.

Thanks.

Feel free to reopen bug 102187 or this if you feel there is a problem.

I would but I can't. Shall I file a new bug?

*** Bug 226344 has been marked as a duplicate of this bug. ***

Reopening for discussion based on comment 33.

Moving from fc2 to fc6 because of bug 226344.

First, fix the Summary (this has nothing to do with language in Gnome anymore)
and then -- could we please consolidate all this madness into bug 225454?

So, what's the plan with this bug? I think Bug 225454#c6 pretty well summarizes
the current situation with zsh init scripts and this one could be closed.

you are right.

*** This bug has been marked as a duplicate of 225454 ***