Re: Terminal issues in fresh install
On Sat, Jan 05, 2008 at 09:31:04AM -0500, Peter Smerdon wrote: Florian Kulzer [EMAIL PROTECTED] writes: On Thu, Jan 03, 2008 at 15:05:10 -0500, Peter Smerdon wrote: [...] Hi, I too have some issue with UTF-8, although I can install and remove software without a problem, my logs get filled with perl warnings about locales. If you want help with that then we need to see the warning messages. from logcheck: Security Events =-=-=-=-=-=-=-= perl: warning: Setting locale failed. perl: warning: Setting locale failed. You could try, as root: dpkg-reconfigure perl and from cron: /etc/cron.daily/man-db: mandb: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct Similarly, dpkg-reconfigure man-db I have found that sometimes a reboot is necessary, and I have no idea why, after changing the locale for the system. See my other posts on this issue in this thread et al. I configured a Lenny system to be fully UTF-8, and it wasn't till *after* a reboot that the debconf screen and the thread indicators started showing correctly. -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Florian Kulzer [EMAIL PROTECTED] writes: The only difference to the setup of your normal user seems to be LANGUAGE. Is there any reason that you reference the iso8859-1 locales there instead of the utf-8 ones? Were the iso8859-1 locales generated on your system? Check if they are listed by locale -a. You could try to unset LANGUAGE for root and see if that stops the complaints of the cronjobs. (I have to admit that I am not even sure about the proper use of LANGUAGE since I have never had any reason to set it on my computers; I only use LANG.) -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | Ok I have unset LANGUAGE for root and will see what happens. I have no idea where the iso8859-1 locales came from, this system has been running unstable for 3 or 4 years now and I cannot remember if I ever messed with locales before. -- Peter Smerdon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Florian Kulzer [EMAIL PROTECTED] writes: On Thu, Jan 03, 2008 at 15:05:10 -0500, Peter Smerdon wrote: [...] Hi, I too have some issue with UTF-8, although I can install and remove software without a problem, my logs get filled with perl warnings about locales. If you want help with that then we need to see the warning messages. from logcheck: Security Events =-=-=-=-=-=-=-= perl: warning: Setting locale failed. perl: warning: Setting locale failed. and from cron: /etc/cron.daily/man-db: mandb: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct I have screen running in utf8 mode now, and with Emacs/gnus reading my mail I can use nice glyphs to display threading, and software still installs or updates despite these warnings so I am not worried too much about it anymore, its more of an annoyance than anything. Thank you for helping! -- Peter Smerdon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Sat, Jan 05, 2008 at 09:31:04 -0500, Peter Smerdon wrote: Florian Kulzer writes: On Thu, Jan 03, 2008 at 15:05:10 -0500, Peter Smerdon wrote: [...] Hi, I too have some issue with UTF-8, although I can install and remove software without a problem, my logs get filled with perl warnings about locales. If you want help with that then we need to see the warning messages. from logcheck: Security Events =-=-=-=-=-=-=-= perl: warning: Setting locale failed. perl: warning: Setting locale failed. and from cron: /etc/cron.daily/man-db: mandb: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct I have screen running in utf8 mode now, and with Emacs/gnus reading my mail I can use nice glyphs to display threading, and software still installs or updates despite these warnings so I am not worried too much about it anymore, its more of an annoyance than anything. Maybe the locale variables are not properly defined for root. What do you get if you run su - -c locale (Or log in as root on the console and check the locale output then. If you normally use su without the - option or sudo to do your root work then you will not necessarily notice a problem with root's own locale definitions.) -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Florian Kulzer [EMAIL PROTECTED] writes: Maybe the locale variables are not properly defined for root. What do you get if you run su - -c locale (Or log in as root on the console and check the locale output then. If you normally use su without the - option or sudo to do your root work then you will not necessarily notice a problem with root's own locale definitions.) I always use sudo to do everything. su - -c locale gives me: ([EMAIL PROTECTED]:/media)% su - -c locale Password: LANG=en_CA.UTF-8 LANGUAGE=en_CA:en_US:en_GB:en LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8 LC_MONETARY=en_CA.UTF-8 LC_MESSAGES=en_CA.UTF-8 LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= This seems ok does it not? -- Peter Smerdon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Sat, Jan 05, 2008 at 15:22:13 -0500, Peter Smerdon wrote: Florian Kulzer writes: Maybe the locale variables are not properly defined for root. What do you get if you run su - -c locale (Or log in as root on the console and check the locale output then. If you normally use su without the - option or sudo to do your root work then you will not necessarily notice a problem with root's own locale definitions.) I always use sudo to do everything. So your upgrading etc. is done with your normal user's locale settings, which seem to work. Comparing them to root's settings will hopefully give us a hint where the problem with the cronjobs lies. su - -c locale gives me: ([EMAIL PROTECTED]:/media)% su - -c locale Password: LANG=en_CA.UTF-8 LANGUAGE=en_CA:en_US:en_GB:en LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8 LC_MONETARY=en_CA.UTF-8 LC_MESSAGES=en_CA.UTF-8 LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= This seems ok does it not? The only difference to the setup of your normal user seems to be LANGUAGE. Is there any reason that you reference the iso8859-1 locales there instead of the utf-8 ones? Were the iso8859-1 locales generated on your system? Check if they are listed by locale -a. You could try to unset LANGUAGE for root and see if that stops the complaints of the cronjobs. (I have to admit that I am not even sure about the proper use of LANGUAGE since I have never had any reason to set it on my computers; I only use LANG.) -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Thu, Jan 03, 2008 at 03:05:10PM -0500, Peter Smerdon [EMAIL PROTECTED] was heard to say: Hi, I too have some issue with UTF-8, although I can install and remove software without a problem, my logs get filled with perl warnings about locales. Which logs? Terminal output? ~/.xsession-errors? /var/log/syslog? ([EMAIL PROTECTED]:~)% locale LANG=en_CA.UTF-8 LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8 LC_MONETARY=en_CA.UTF-8 LC_MESSAGES=en_CA.UTF-8 LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= As you can see LC_ALL is unset, I use rxvt-unicode and can see special characters except inside GNU Screen for some reason. How do I set LC_ALL the `debian way'? I'm not sure setting LC_ALL is your problem; as I understand it, setting everthing else should be equivalent to setting LC_ALL. The only things I can think of off the top of my head are: (for the log file thing) (1) You're running some sort of apt cronjob, and locales aren't set for that. It looks like they should be set in /etc/default/locale by the locales package (run dpkg-reconfigure locales to regenerate that file), although I'm not quite sure how they get pulled into cron's environment. From crontab(5), it looks like it just takes whatever is set in cron's environment. You could work around this by setting them explicitly in /etc/crontab, although that's probably papering over some other problem. (for screen) (2) Somehow your shell startup scripts are zapping the locale in screen, but not outside. I don't know how this would happen, but you could check it by running locale inside and outside. (3) For some reason (e.g., check ~/.screenrc), screen is using the wrong encoding. You could try starting screen with the -U option, or by typing C-a :, then entering encoding UTF-8 at the prompt. See the screen manpage for details. Someone who actually knows locales might have a better idea than me. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Thu, Jan 03, 2008 at 15:05:10 -0500, Peter Smerdon wrote: [...] Hi, I too have some issue with UTF-8, although I can install and remove software without a problem, my logs get filled with perl warnings about locales. If you want help with that then we need to see the warning messages. ([EMAIL PROTECTED]:~)% locale LANG=en_CA.UTF-8 LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8 LC_MONETARY=en_CA.UTF-8 LC_MESSAGES=en_CA.UTF-8 LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= As you can see LC_ALL is unset, You don't have to set LC_ALL since you have already defined all the other ones. Setting LC_ALL is just a shortcut to set all the LC_* variables to the same locale at once. I use rxvt-unicode and can see special characters except inside GNU Screen for some reason. Maybe screen runs a different shell on your system and/or does not get initialized the same way as your normal shell. Run locale from within screen to check if the settings are correct. How do I set LC_ALL the `debian way'? The system-wide locale settings are in /etc/default/locale or /etc/environment. (I think /etc/environment is depreciated these days.) See also man update-locale. If you want to customize the settings on a per-user basis then you have to make sure that each user's shell(s) get initialized as desired and that the relevant LC_* environmental variables are set correctly for all X applications. (How to do the X part depends on how you start X and which DE you use.) -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Wed, Jan 02, 2008 at 09:45:06PM -0800, Daniel Burrows wrote: On Thu, Jan 03, 2008 at 01:50:42PM +1300, Chris Bannister [EMAIL PROTECTED] was heard to say: On Mon, Dec 31, 2007 at 05:19:52PM -0800, Daniel Burrows wrote: I'd guess that the locale of the workstation is relevant here. Your terminal is going to be running in your locale (you didn't mention if was the system console or an X terminal, but I assume an X terminal), and so it won't know how to deal with UTF-8 sequences output by the commands you're running remotely. Probably your best bet is to either enable UTF-8 locally or disable it remotely. Hi Daniel, I see that you are using mutt. Are you using a UTF-8 locale and also get the thread indicators to show correctly? Or are you using a UTF-8 locale but have something like export LC_CTYPE=en_US in your .bashrc I've been using a full UTF-8 locale since 2005. I don't have any problems with the thread indicators, and I don't recall having any anytime recently. I have just tried commenting out the LC_CTYPE=en_NZ and logging out/in then starting mutt and it's now working. (red faced emoticon goes here.) It definately wasn't working at some stage earlier. It may have something to do with: * adding vga=791 to kernel line in grub (just tried without that option and its still ok) * not actually trying it since upgrading fully to etch Should of tested one last time before posting. -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SOLVED: Reconfiguring package configuration interface (was Re: Terminal issues in fresh install)
OK, my questions on mutt and the en_US.UTF-8 package have been answered pretty thoroughly (thanks, all!), but nobody's touched on my other question. Just to get the answer into the archive for the sake of others who may have the same question (or to remind myself in a couple years...) now that I've figured it out (again): On Mon, Dec 31, 2007 at 06:23:52PM -0600, Dave Sherohman wrote: ...Package configurations are... ...using the (default) curses interface. Which I've never liked anyway. How do I switch it over to the plain-text (readline?) interface? I've tried dpkg-reconfigure dpkg and apt, since they seemed the likely suspects, but neither one offered any options to configure. This is controlled by the debconf package rather than apt/dpkg directly, so 'dpkg-reconfigure debconf' will take care of it. -- I reckon we are now the only monastry ever that had a dungeon stuffed with sixteen thousand zombies. - perlmonks.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Daniel Burrows [EMAIL PROTECTED] writes: btw, my locale(1) outputs: [EMAIL PROTECTED] locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL=en_US.UTF-8 Hi, I too have some issue with UTF-8, although I can install and remove software without a problem, my logs get filled with perl warnings about locales. ([EMAIL PROTECTED]:~)% locale LANG=en_CA.UTF-8 LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8 LC_MONETARY=en_CA.UTF-8 LC_MESSAGES=en_CA.UTF-8 LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= As you can see LC_ALL is unset, I use rxvt-unicode and can see special characters except inside GNU Screen for some reason. How do I set LC_ALL the `debian way'? -- Peter Smerdon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
David [EMAIL PROTECTED] wrote: Thomas Dickey wrote: Daniel Burrows [EMAIL PROTECTED] wrote: IIRC there was a situation a few years ago where you had to install a Unicode-enabled xterm, pass -u, or both. Sarge dates to 2005; I'm sure that there were X terminals in 2005 that could handle UTF-8, but I don't know if the default xterm did. xterm's supported UTF-8 since 1999: http://invisible-island.net/xterm/xterm.log.html (likewise, it's been possible to change the encoding) Default xterm doesn't but if you want xterm with utf-8, that's another xterm install option. hmm - the context is Debian (not the configure-script defaults). iirc, Debian's packaged xterm using the wide-character support since 2002 or so. (Unsure what else you could mean by another xterm install option). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Mon, Dec 31, 2007 at 05:19:52PM -0800, Daniel Burrows wrote: I'd guess that the locale of the workstation is relevant here. Your terminal is going to be running in your locale (you didn't mention if was the system console or an X terminal, but I assume an X terminal), and so it won't know how to deal with UTF-8 sequences output by the commands you're running remotely. Probably your best bet is to either enable UTF-8 locally or disable it remotely. Hi Daniel, I see that you are using mutt. Are you using a UTF-8 locale and also get the thread indicators to show correctly? Or are you using a UTF-8 locale but have something like export LC_CTYPE=en_US in your .bashrc I use mutt in the system console and can't seem to strike the right combination. If I generate a UTF-8 locale I need to set LC_CTYPE=en_NZ which seems to defeat the purpose of generating UTF-8 in the first place. Also dpkg-reconfigure shows rubbish unless LC_CTYPE is set similarly for root. -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Thu, Jan 03, 2008 at 01:50:42PM +1300, Chris Bannister [EMAIL PROTECTED] was heard to say: On Mon, Dec 31, 2007 at 05:19:52PM -0800, Daniel Burrows wrote: I'd guess that the locale of the workstation is relevant here. Your terminal is going to be running in your locale (you didn't mention if was the system console or an X terminal, but I assume an X terminal), and so it won't know how to deal with UTF-8 sequences output by the commands you're running remotely. Probably your best bet is to either enable UTF-8 locally or disable it remotely. Hi Daniel, I see that you are using mutt. Are you using a UTF-8 locale and also get the thread indicators to show correctly? Or are you using a UTF-8 locale but have something like export LC_CTYPE=en_US in your .bashrc I've been using a full UTF-8 locale since 2005. I don't have any problems with the thread indicators, and I don't recall having any anytime recently. On the other hand, if I start an xterm (by hand) in a non-UTF-8 locale, then change the locale to UTF-8 and run mutt, I get messed up thread indicators. Selecting the UTF-8 menu option Thomas pointed out in this thread and hitting C-l fixes everything right up, though. Could that be your problem? btw, my locale(1) outputs: [EMAIL PROTECTED] locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL=en_US.UTF-8 Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Mon, Dec 31, 2007 at 05:19:52PM -0800, Daniel Burrows wrote: On Mon, Dec 31, 2007 at 06:23:52PM -0600, Dave Sherohman [EMAIL PROTECTED] was heard to say: Is it significant that the old machine was using the basic en_US locale or that I've been accessing both of them via ssh from a workstation with its locale set to C? I'd guess that the locale of the workstation is relevant here. Your terminal is going to be running in your locale (you didn't mention if was the system console or an X terminal, but I assume an X terminal), and so it won't know how to deal with UTF-8 sequences output by the commands you're running remotely. Probably your best bet is to either enable UTF-8 locally or disable it remotely. Thanks for the suggestion. Building the en_US.UTF-8 locale on the workstation and exporting LANG=en_US.UTF-8 in the window used to connect to the server (your assumption of an X terminal is accurate) had no discernible effect, but setting LANG=C on the server did get the ASCII graphics working correctly. The workstation is still running the previous stable version (I haven't talked myself into dealing with working out the configuration for switching from XFree86 to x.org yet), so perhaps my X terminals are just too old to be able to handle UTF-8, regardless of the locale. -- I reckon we are now the only monastry ever that had a dungeon stuffed with sixteen thousand zombies. - perlmonks.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Tue, Jan 01, 2008 at 12:48:04PM -0600, Dave Sherohman [EMAIL PROTECTED] was heard to say: On Mon, Dec 31, 2007 at 05:19:52PM -0800, Daniel Burrows wrote: On Mon, Dec 31, 2007 at 06:23:52PM -0600, Dave Sherohman [EMAIL PROTECTED] was heard to say: Is it significant that the old machine was using the basic en_US locale or that I've been accessing both of them via ssh from a workstation with its locale set to C? I'd guess that the locale of the workstation is relevant here. Your terminal is going to be running in your locale (you didn't mention if was the system console or an X terminal, but I assume an X terminal), and so it won't know how to deal with UTF-8 sequences output by the commands you're running remotely. Probably your best bet is to either enable UTF-8 locally or disable it remotely. Thanks for the suggestion. Building the en_US.UTF-8 locale on the workstation and exporting LANG=en_US.UTF-8 in the window used to connect to the server (your assumption of an X terminal is accurate) had no discernible effect, but setting LANG=C on the server did get the ASCII graphics working correctly. Note that just changing the environment variable inside the terminal won't help -- it's the terminal that needs to interpret those sequences, so you have to run *the terminal itself* in the new locale. I just ended up setting my locale in ~/.xsession to make it stick: export LC_ALL=en_US.UTF-8 export LC_CTYPE=en_US.UTF-8 export LANG=en_US.UTF-8 The workstation is still running the previous stable version (I haven't talked myself into dealing with working out the configuration for switching from XFree86 to x.org yet), so perhaps my X terminals are just too old to be able to handle UTF-8, regardless of the locale. IIRC there was a situation a few years ago where you had to install a Unicode-enabled xterm, pass -u, or both. Sarge dates to 2005; I'm sure that there were X terminals in 2005 that could handle UTF-8, but I don't know if the default xterm did. On the other hand, if you have no need for Unicode, just changing the remote end to C is probably the simplest option. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On 2008-01-01 20:57 +0100, Daniel Burrows wrote: Note that just changing the environment variable inside the terminal won't help -- it's the terminal that needs to interpret those sequences, so you have to run *the terminal itself* in the new locale. Some terminals also allow to change the encoding at runtime, e.g. KDE konsole or putty. I just ended up setting my locale in ~/.xsession to make it stick: export LC_ALL=en_US.UTF-8 export LC_CTYPE=en_US.UTF-8 export LANG=en_US.UTF-8 The last two lines here are actually redundant. IIRC there was a situation a few years ago where you had to install a Unicode-enabled xterm, pass -u, or both. Sarge dates to 2005; I'm sure that there were X terminals in 2005 that could handle UTF-8, but I don't know if the default xterm did. It did; the uxterm wrapper that always starts an xterm in UTF-8 mode was already present then, according to http://packages.debian.org/sarge/xterm. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Daniel Burrows [EMAIL PROTECTED] wrote: IIRC there was a situation a few years ago where you had to install a Unicode-enabled xterm, pass -u, or both. Sarge dates to 2005; I'm sure that there were X terminals in 2005 that could handle UTF-8, but I don't know if the default xterm did. xterm's supported UTF-8 since 1999: http://invisible-island.net/xterm/xterm.log.html (likewise, it's been possible to change the encoding) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Sven Joachim [EMAIL PROTECTED] wrote: On 2008-01-01 20:57 +0100, Daniel Burrows wrote: Note that just changing the environment variable inside the terminal won't help -- it's the terminal that needs to interpret those sequences, so you have to run *the terminal itself* in the new locale. Some terminals also allow to change the encoding at runtime, e.g. KDE konsole or putty. xterm does that as well (control sequences, or menu entry) It doesn't adjust the fonts though, so it's possible to start it with an ISO-8859-1 font and switch to UTF-8, making it recognize but not display various characters. That's the point of the uxterm script - to make it simple. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
Thomas Dickey wrote: Daniel Burrows [EMAIL PROTECTED] wrote: IIRC there was a situation a few years ago where you had to install a Unicode-enabled xterm, pass -u, or both. Sarge dates to 2005; I'm sure that there were X terminals in 2005 that could handle UTF-8, but I don't know if the default xterm did. xterm's supported UTF-8 since 1999: http://invisible-island.net/xterm/xterm.log.html (likewise, it's been possible to change the encoding) Default xterm doesn't but if you want xterm with utf-8, that's another xterm install option. All you have to do is ensure you have en-USutf-8 installed as a locales option, and xterm utf-8 will pick it up. Regards, -- David Palmer Linux User - #352034 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Terminal issues in fresh install
Greetings, all! I've just moved over from an ancient self-hosted Debian box onto some more modern hardware and things are going mostly smoothly, but I'm having some issues with mutt's thread indicators (extended-ASCII arrows) displaying improperly. I've double-checked that I've got all locale settings set to en_US.UTF-8 (with the sole exception of LC_COLLATE, which I prefer to keep at C) and done a dkpg-reconfigure locales to verify that en_US.UTF-8 is generated (it is; actually, it's the only thing that is). mutt is at the latest version from stable and, noticing that there's a mutt-utf8 mentioned as conflicting with it, I tried installing that, but it appears to be an obsolete UTF-8 support package which no longer exists. Is it significant that the old machine was using the basic en_US locale or that I've been accessing both of them via ssh from a workstation with its locale set to C? I also am using a customized terminfo (to prevent the screen from resetting when I exit less/vi/etc.), but tried disabling that and relogging, which had no effect, so I don't think it's likely to be the cause. As a side question, this new install was done by the hosting provider, who is primarily familiar with Red Hat, so everything was configured to the defaults. Package configurations are also displaying the same symptoms as mutt, since they're using the (default) curses interface. Which I've never liked anyway. How do I switch it over to the plain-text (readline?) interface? I've tried dpkg-reconfigure dpkg and apt, since they seemed the likely suspects, but neither one offered any options to configure. -- I reckon we are now the only monastry ever that had a dungeon stuffed with sixteen thousand zombies. - perlmonks.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Terminal issues in fresh install
On Mon, Dec 31, 2007 at 06:23:52PM -0600, Dave Sherohman [EMAIL PROTECTED] was heard to say: Is it significant that the old machine was using the basic en_US locale or that I've been accessing both of them via ssh from a workstation with its locale set to C? I'd guess that the locale of the workstation is relevant here. Your terminal is going to be running in your locale (you didn't mention if was the system console or an X terminal, but I assume an X terminal), and so it won't know how to deal with UTF-8 sequences output by the commands you're running remotely. Probably your best bet is to either enable UTF-8 locally or disable it remotely. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
