Re: [Perl/locales] Warning about locales
--- Philip Guenther [EMAIL PROTECTED] wrote: pOn Sun, Jun 15, 2008 at 12:46 PM, F. Caulier [EMAIL PROTECTED] wrote: --- Pieter Verberne [EMAIL PROTECTED] wrote: On Sun, Jun 15, 2008 at 07:20:32AM -0700, F. Caulier wrote: I get the following when I (as root and standard user) execute pkg_info, pkg_add or pkg_delete with Xorg on: # pkg_info perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset) LC_CTYPE = en_US.UTF-8, LANG = (unset) are supported and installed on your system. perl: warning: Falling back to standard locale (C). So something has set LC_CTYPE to en_US.UTF-8, a locale which is not supported by OpenBSD, which results in the setlocale() call failing, something perl complains about so that you don't blame perl when you get broken results. ... I found a workaround: # ln -s /usr/share/locale/en_GB.ISO8859-1 /usr/share/locale/en_US.UTF-8 That seems like a really bad idea to me. UTF-8 and ISO8859-1 are fundamentally different: UTF-8 uses variable-length characters while ISO8859-* uses fixed-width (8bit) characters. Giving the locale calls the same data for those two is likely to result in incorrect behavior for all characters 127. Wouldn't it be better to simply not lie and just set the locale to en_US.ISO8859-1? The point is that, I didn't changed anything related locales and I couldn't find any config files where these locales are specified. So I'm wondering why this problem appears if I didn't change anything. Well, have you examined all the programs involved in getting to that shell inside xterm to see if any of them document that they alter the environment? For example, if you use 'uxterm' instead of 'xterm' then you'll see exactly the above behavior, as uxterm is just a script that sets LC_CTYPE=en_US.UTF-8 and then invokes xterm with the -en option. If nothing obvious sticks out, consider debugging further by checking the environment seen by your .xsession (if you xdm) by adding a line like this: env $HOME/.xsession-env.out to it. Similarly, check the shell's environment by doing something similar from your .profile. I tried to figure out why this problem occurs and following to that I noticed that this perllocale warning only comes up when dropping a pkg_* directly in xterm. When using screen in an xterm and dropping pkg_* to it everything will work fine. Same for tty shells without X where everything works fine too. Windows inside screen inherit their environment from the original screen process. So, how do you start the initial (daemon) screen process? From outside X, before running xinitrc? From your .xinitrc or .xsession? From an xterm? I don't know much about this terminal stuff, but if everything beside XTerm works fine, could it be that XTerm itself and not the locales are the problems' source? Maybe XTerm doesn't manage to pass on the locales correctly? Something is setting LC_CTYPE to an unsupported value. That's the program that needs to be fixed. Some questions: - Is this bug a dangerous one or can I ignore it safely? perl complains about it because you may get bogus results from various operations. That doesn't sound ignorable to me. - Is this a bug related to XTerm? Insufficient data. - Should I set the LC_TYPE and LANG variables in /etc/login.conf? (Is this a clean solution?) Why do you think that would solve the problem? - If I want to get the OpenBSD's default locale (is this C/POSIX or another one?) back what file should I link to whom? (Following Pieter's workaround) Why would you do that instead of simply not setting LC_CTYPE? - What about copying a CL_TYPE file from [0] in to the concerned directory which is listed by perl? The files in cvs are in a human-readable text source format that needs to be 'compiled' into a binary format used by the locale subsystem, so simply copying them would be a Bad Thing. Beyond that, there's the question of whether the locale code in the C library will actually handle the locale data for the *.UTF-8 locales. My guess is that the answer is no and that it simply won't work. After all, if it did, you would expect the OpenBSD developers to have included them in the normal builds and distributions. Making the locale stuff work 100% correctly is quite complicated and is still, as I understand it, a work-in-progress. In the meantime, using the ISO8859-1 locales instead of the UTF-8 locales is still, IIRC, the recommended course. Philip Guenther Thank you very much for this very helpful post. As I have some plan9port programs running on the concerned machine I thought that maybe these are responsible for setting this UTF-8 locale (as Plan 9 is pure UTF
[Perl/locales] Warning about locales
I get the following when I (as root and standard user) execute pkg_info, pkg_add or pkg_delete with Xorg on: # pkg_info perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset) LC_CTYPE = en_US.UTF-8, LANG = (unset) are supported and installed on your system. perl: warning: Falling back to standard locale (C). USUAL/NORMAL OUTPUT FOLLOWS If I do this directly in a ttyCx when Xorg is off, I don't get any error messages. The point is that, I didn't changed anything related locales and I couldn't find any config files where these locales are specified. So I'm wondering why this problem appears if I didn't change anything. (Obviously I must've changend something without seeing it, but what and where?) If I manually set/export LC_ALL and LANG as C, Perl stops complaining. How can I fix this problem? I'm using OpenBSD-4.3, GENERIC Kernel and pdksh.
Re: [Perl/locales] Warning about locales
--- Pieter Verberne [EMAIL PROTECTED] wrote: On Sun, Jun 15, 2008 at 07:20:32AM -0700, F. Caulier wrote: I get the following when I (as root and standard user) execute pkg_info, pkg_add or pkg_delete with Xorg on: # pkg_info perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset) LC_CTYPE = en_US.UTF-8, LANG = (unset) are supported and installed on your system. perl: warning: Falling back to standard locale (C). I had the same problem. See http://perldoc.perl.org/perllocale.html . But I havn't used that site for my solution. I found a workaround: # ln -s /usr/share/locale/en_GB.ISO8859-1 /usr/share/locale/en_US.UTF-8 The point is that, I didn't changed anything related locales and I couldn't find any config files where these locales are specified. So I'm wondering why this problem appears if I didn't change anything. Me too. Pieter Verberne Thanks for your fast reply. I tried to figure out why this problem occurs and following to that I noticed that this perllocale warning only comes up when dropping a pkg_* directly in xterm. When using screen in an xterm and dropping pkg_* to it everything will work fine. Same for tty shells without X where everything works fine too. I don't know much about this terminal stuff, but if everything beside XTerm works fine, could it be that XTerm itself and not the locales are the problems' source? Maybe XTerm doesn't manage to pass on the locales correctly? Some questions: - Is this bug a dangerous one or can I ignore it safely? - Is this a bug related to XTerm? - Should I set the LC_TYPE and LANG variables in /etc/login.conf? (Is this a clean solution?) - If I want to get the OpenBSD's default locale (is this C/POSIX or another one?) back what file should I link to whom? (Following Pieter's workaround) - What about copying a CL_TYPE file from [0] in to the concerned directory which is listed by perl? [0] http://www.openbsd.org/cgi-bin/cvsweb/src/share/locale/ctype/?only_with_tag=OPENBSD_4_3_BASE
Re: captivating window manager
--- Pieter Verberne [EMAIL PROTECTED] wrote: I'm working almost only full screen. So DWM is not -that- usefull for me actually. I had a look on CWM first cause it was in base, and finaly I found it more attractive. Taste matter. ( CWM's binary is almost twice the size of DWM:) 32.0K /usr/bin/dwm 52.0K /usr/X11R6/bin/cwm But I really don't know about libraries and memory usage etc. ) What I need is a GNU-Screen-like graphical-window-manager. Smaller than DWM and have a permissive license. Do you know 'ratpoison' [0]? It's not under a permissive license nor smaller than dwm, but it's GNU-Screen-like. If you plan to develop a window manager which is GNU-Screen-like, smaller than dwm and under a permissive license, then drop me line as I'd be really interested. [0] http://www.nongnu.org/ratpoison/
Get rid of windows limit in 'window'?
I just discovered 'window' in base, a very usefull tool! I was used to install 'screen' to get a terminal multiplexer but as I found 'window' which gives me multiplexing without 'screen's' bloat and restrictive license. Just two questions: Is there an example.windowrc available somewhere or would someone be so kind a send me his own customized one? I already searched the web on this but couldn't find much. Is there a way to go beyond the limit of 9 windows beside executing 'window' in 'window'? Suggestions welcome
[Error code 1] Compiling -STABLE fails
I'm currently trying to follow the -STABLE branch, so I followed all the instructions found in ttp://openbsd.org/stable.html until building the kernel with 'make clean make depend make'. This is what I get: #: make clean make depend make rm -f eddep *bsd bsd.gdb tags *.[io] [a-z]*.s [Ee]rrs linterrs makelinks assym.h rm -f param.c cp /usr/src/sys/arch/i386/compile/GENERIC/../../../../conf/param.c cp: ./param.c: Permission denied *** Error code 1 Stop in /usr/src/sys/arch/i386/compile/GENERIC (line 812 of Makefile). #: I use OpenBSD-4.3, GENERIC Kernel and also tried fetching the tree from different anoncvs servers ([EMAIL PROTECTED]:/cvs, [EMAIL PROTECTED]:/cvs, [EMAIL PROTECTED]:/cvs) Suggestions welcome
Problems installing OpenBSD-4.3 using bsd.rd
Hello I'm currently trying to install OpenBSD-4.3 on my subnotebook (JVC MP-XP3), the problem is that it doesn't have any CD-ROM and/or floppy drive and it isn't capable of booting using PXE nor booting from USB-HDD. (Already checked that) I read in the FAQ that there's a possibility to install OpenBSD from harddisk through bsd.rd, so I downloaded the latest (4.3-RELEASE) bsd.rd, put it on a small separate partition in a directory named /boot, modified the Grub menu and tried to boot that. It didn't work out, here's what I get: panic: /boot too old: upgrade! The operating system has halted. Please press any key to reboot After this I thought that maybe bsd.rd needs some other files which it expects to be usually found in /boot. So I downloaded cd43.iso, extracted its contents to /boot and retried. Still the same problem. Following to that I also tried with install43.iso, same procedure, but the problem remains. The Grub menu entry I used for the 2nd and 3rd try: root (hd0,3) kernel --openbsd=openbsd /boot/4.3/i386/bsd.rd In the FAQ, section 4.11 it says: [0] ... if you have a running older version of OpenBSD, ... Does this probably mean that the install method with bsd.rd is only possible if there's already an OpenBSD system existing on the harddisk? If that's correct, is there any other suitable installation method using a install-image on a harddisk? Currently I don't have any more ideas, beside the following: I could install OpenBSD on an other (totally different) computer using the standard CD-ROM install method, after that I'd copy the hole system to an USB-HDD which in turn I would plug to my subnotebook. There I'd copy the hole system to a temporary partition, download the latest (4.3) bsd.rd again, edit the Grub menu and retry to boot the bsd.rd. I already searched the web for other installing methods suitable for my case and searched further if there's a possibility of directly booting .iso images using Grub but couldn't find anything useful. Suggestions most welcome Thanks, ~fc [0] http://www.openbsd.org/faq/faq4.html#bsd.rd
