Re: Claws Mail and new call for eu locale

[Ingo Schwarze]

Hi,

Daniele B. wrote on Wed, Nov 15, 2023 at 06:17:21PM +0100:

> I just came accross the last little problem regarding the locale of my
> system: in Claws Mail the date in message pane is displayed in %x
> format (result=mm/dd/year) to adapt to the current locale. 
> 
> I started to change locale to my system in all the possible ways
> without luck. If I set it_IT I got yes the right language but the same
> result for the date (in the message pane).
> 
> In the end going in Claws Mail display settings the option allows me
> to specify the parameters for the date format. "man strftime" I found
> something useful (an year/mm/dd), although not exactly a simple
> dd/mm/year format yet.
> 
> Dispite these details and knowing that en_US.UTF-8 with "C" locale
> profile is reccomnded to us, I take the time to gently ask about
> the support for any european date locale profile and any feedback
> about any eventual work-in-progress?

Even if someone would provide libc patches to provide LC_* support
other than LC_CTYPE, i would veto them, even if they were correct and
very simple (they cannot be simple, though).  Reliable and predictable
output is much more important than such quibbles.  The C library is
totally the wrong place for any such functionality.

Yours,
  Ingo

Re: httpd and locale

[Manuel Giraud]

Omar Polo  writes:

> On 2023/01/30 15:57:03 +0100, Manuel Giraud  wrote:
>> Hi,
>> 
>> Is it possible to serve files with non ASCII UTF-8 charaters in their
>> names with httpd?  I have tried to start httpd like this:
>> 
>>   $ env LC_CTYPE=en_US.UTF-8 httpd -d
>> 
>> But, I always get a 404 error on such files.  Am I missing something?
>> Or maybe this behaviour is on purpose?
>
> The encoding of the filename shouldn't matter.  UNIX file names are
> just bytestrings where only '/' and '\0' are disallowed.

Thanks for this explanation!  I was wrong.  httpd is not the cause here.
A file was upload through a CMS and store as latin-1 in base and then
copied over by another mean (that should have translate it to UTF-8).
Encodings problems are fun :-|  Sorry for the noise.
-- 
Manuel Giraud

Re: httpd and locale

[Omar Polo]

On 2023/01/30 15:57:03 +0100, Manuel Giraud  wrote:
> Hi,
> 
> Is it possible to serve files with non ASCII UTF-8 charaters in their
> names with httpd?  I have tried to start httpd like this:
> 
>   $ env LC_CTYPE=en_US.UTF-8 httpd -d
> 
> But, I always get a 404 error on such files.  Am I missing something?
> Or maybe this behaviour is on purpose?

The encoding of the filename shouldn't matter.  UNIX file names are
just bytestrings where only '/' and '\0' are disallowed.

I'm able to serve a file generated as such:

% filename="$(printf '<\a\a\a\n\t\x8f>')"
% date >$filename

so it should work.

How are you trying to fetch the file?  which which client?  is the
client correctly percent-encoding/decoding the filenames?

a "good" request should show up in logs like

localhost ::1 - - [30/Jan/2023:19:18:20 +0100] "GET //%3C%07%07%07%0A%09%8F> 
HTTP/1.1" 200 29

httpd and locale

[Manuel Giraud]

Hi,

Is it possible to serve files with non ASCII UTF-8 charaters in their
names with httpd?  I have tried to start httpd like this:

  $ env LC_CTYPE=en_US.UTF-8 httpd -d

But, I always get a 404 error on such files.  Am I missing something?
Or maybe this behaviour is on purpose?

Thanks.
-- 
Manuel Giraud

Re: locale settings for spelling, paper size, etc

[Austin Hook]

On Mon, 26 Mar 2018, Allan Streib wrote:
> That suggestion of aoubt:config prompted me to look, there are several
> print.print_paper_* settings, have you tried those?
> 
> This post indicates that print.print_paper_name may be the way...
> 
>   
> https://superuser.com/questions/184476/how-to-set-default-page-setup-%e2%86%92page-size-as-a4-in-firefox#309175
> ... but it doesn't work for me in FF 58.0.2
> I see the following:
> print.print_paper_data  integer 0
> print.print_paper_heightstring  11.69
> print.print_paper_name  string  iso_a4
> print.print_paper_size  integer 0
> print.print_paper_size_unit integer 0
> print.print_paper_width stirng  8.27
> 
> I have tried resetting to default, tried "letter" and "na_letter" as the
> print_paper_name, but the print dialog always defaults to A4 regardless.
> 
> > Keep telling myself to look for a change to compile in, but shudder to
> > think of building Firefox.
> 
> Agreed. I tried once and after quite some time if failed for lack of
> resources (don't remember exactly what, now).
> 
> Allan

Yes, I tried everything I could think of in about:config release after 
release.

Re: locale settings for spelling, paper size, etc

[Allan Streib]

Austin Hook  writes:

> I have for a long time set my /etc/papersize to "letter".  In my 
> experience Firefox ignores it.  At some point the default setup for the 
> Firefox package became A4 and I have to manually re-set it to letter, 
> manually in the pop-up, whenever I print.  Can't make it default to 
> letter.  Can't find an about:config for Firefox that works for me.

That suggestion of aoubt:config prompted me to look, there are several
print.print_paper_* settings, have you tried those?

This post indicates that print.print_paper_name may be the way...

  
https://superuser.com/questions/184476/how-to-set-default-page-setup-%e2%86%92page-size-as-a4-in-firefox#309175

... but it doesn't work for me in FF 58.0.2

I see the following:

print.print_paper_data  integer 0
print.print_paper_heightstring  11.69
print.print_paper_name  string  iso_a4
print.print_paper_size  integer 0
print.print_paper_size_unit integer 0
print.print_paper_width stirng  8.27

I have tried resetting to default, tried "letter" and "na_letter" as the
print_paper_name, but the print dialog always defaults to A4 regardless.

> Keep telling myself to look for a change to compile in, but shudder to
> think of building Firefox.

Agreed. I tried once and after quite some time if failed for lack of
resources (don't remember exactly what, now).

Allan

Re: locale settings for spelling, paper size, etc

[Austin Hook]

I have for a long time set my /etc/papersize to "letter".  In my 
experience Firefox ignores it.  At some point the default setup for the 
Firefox package became A4 and I have to manually re-set it to letter, 
manually in the pop-up, whenever I print.  Can't make it default to 
letter.  Can't find an about:config for Firefox that works for me. And it 
doesn't even remember for the next print you do a few minutes later.  
Suspect it's hardwired in by the ports developers.  Keep telling myself to 
look for a change to compile in, but shudder to think of building Firefox.  

Any shortcut would be much appreciated.

Using AMD64, OpenBSD 6.2

Austin








On Tue, 13 Mar 2018, Paul de Weerd wrote:

> On Tue, Mar 13, 2018 at 12:33:28PM -0700, Chris Bennett wrote:
> | > Seems like a FAQ, though I didn't find it. I've noticed that in
> | > applications such as Firefox, LibreOffice, etc. the spell checking uses
> | > British English spelling. Also printing defaults to A4 instead of
> | > US-Letter paper size.
> | > 
> | > I select us.swapctrlcaps keyboard when installing, and
> | > LC_CTYPE=en_US.UTF-8.
> | > 
> | > Is this something I just need to change per application, or is there
> | > another system-wide way to indicate I want American defaults?
> | > 
> | > Allan
> | > 
> | 
> | /etc/papersize
> | read man papersize
> | it defaults to A4
> 
> That's not what papersize(5) tells me on my system:
> 
>   If the papersize file does not exist, programs using
>   the paper library default to using letter as a fall-
>   back value
> 
> (I was unaware of papersize(5), so I looked it up .. apparently it's
> from libpaper which is a dependency of several other packages)
> 
> Cheers,
> 
> Paul 'WEiRD' de Weerd
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

Re: locale settings for spelling, paper size, etc

[Paul de Weerd]

On Tue, Mar 13, 2018 at 12:33:28PM -0700, Chris Bennett wrote:
| > Seems like a FAQ, though I didn't find it. I've noticed that in
| > applications such as Firefox, LibreOffice, etc. the spell checking uses
| > British English spelling. Also printing defaults to A4 instead of
| > US-Letter paper size.
| > 
| > I select us.swapctrlcaps keyboard when installing, and
| > LC_CTYPE=en_US.UTF-8.
| > 
| > Is this something I just need to change per application, or is there
| > another system-wide way to indicate I want American defaults?
| > 
| > Allan
| > 
| 
| /etc/papersize
| read man papersize
| it defaults to A4

That's not what papersize(5) tells me on my system:

If the papersize file does not exist, programs using
the paper library default to using letter as a fall-
back value

(I was unaware of papersize(5), so I looked it up .. apparently it's
from libpaper which is a dependency of several other packages)

Cheers,

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: locale settings for spelling, paper size, etc

[Chris Bennett]

On Tue, Mar 13, 2018 at 05:17:26PM +, Allan Streib wrote:
> Seems like a FAQ, though I didn't find it. I've noticed that in
> applications such as Firefox, LibreOffice, etc. the spell checking uses
> British English spelling. Also printing defaults to A4 instead of
> US-Letter paper size.
> 
> I select us.swapctrlcaps keyboard when installing, and
> LC_CTYPE=en_US.UTF-8.
> 
> Is this something I just need to change per application, or is there
> another system-wide way to indicate I want American defaults?
> 
> Allan
> 

/etc/papersize
read man papersize
it defaults to A4

Chris Bennett

PS this drove me crazy too

locale settings for spelling, paper size, etc

[Allan Streib]

Seems like a FAQ, though I didn't find it. I've noticed that in
applications such as Firefox, LibreOffice, etc. the spell checking uses
British English spelling. Also printing defaults to A4 instead of
US-Letter paper size.

I select us.swapctrlcaps keyboard when installing, and
LC_CTYPE=en_US.UTF-8.

Is this something I just need to change per application, or is there
another system-wide way to indicate I want American defaults?

Allan

PostgreSQL 9.4: initdb: invalid locale settings

[opendaddy]

Hello,

Why won't `postgresql-server-9.4.0` accept my locale? Just upgraded to 5.7 from 
5.5. Whatever `postgresql-server` version was in 5.5 didn't have this problem.

% su _postgresql
% initdb -D /var/postgresql/data/
The files belonging to this database system will be owned by user 
_postgresql.
This user must also own the server process.
initdb: invalid locale settings; check LANG and LC_* environment variables

`env` says `LC_ALL=en_US.UTF-8`, which according to `locale -a` does exist.

Thanks.

O.D.

Re: PostgreSQL 9.4: initdb: invalid locale settings

[frantisek holop]

openda...@hushmail.com, 21 Jan 2015 19:29:
 Why won't `postgresql-server-9.4.0` accept my locale? Just upgraded to 5.7 
 from 5.5. Whatever `postgresql-server` version was in 5.5 didn't have this 
 problem.
 
 % su _postgresql
 % initdb -D /var/postgresql/data/

LC_ALL is not supported yet, try LC_CTYPE.

$ sudo su - _postgresql
$ export LC_CTYPE=en_US.UTF-8
$ initdb -D /var/postgresql/data -U postgres -E UTF8 -A md5 -W
$ psql -U postgres -l
Password for user postgres:
List of databases
   Name|  Owner   | Encoding | Collate |Ctype|   Access privileges
---+--+--+-+-+---
 postgres  | postgres | UTF8 | C   | en_US.UTF-8 |
 template0 | postgres | UTF8 | C   | en_US.UTF-8 | =c/postgres  
+
   |  |  | | | postgres=CTc/postgres
 template1 | postgres | UTF8 | C   | en_US.UTF-8 | =c/postgres  
+
   |  |  | | | postgres=CTc/postgres
(3 rows)

-f
-- 
if practice makes perfect, and nobody's perfect, why practice?

Re: PostgreSQL 9.4: initdb: invalid locale settings

[frantisek holop]

openda...@hushmail.com, 21 Jan 2015 20:41:
 Hello,
 
 On 21. januar 2015 at 8:26 PM, frantisek holop min...@obiit.org wrote:
 
 LC_ALL is not supported yet, try LC_CTYPE.
 
 $ sudo su - _postgresql
 $ export LC_CTYPE=en_US.UTF-8
 $ initdb -D /var/postgresql/data -U postgres -E UTF8 -A md5 -W
 $ psql -U postgres -l
 
 I couldn't get it to work with `LC_CTYPE`. It did, however, work with `initdb 
 -D /var/postgresql/data/ --no-locale`.

you are not giving details, so i don't know.
but a non-utf8 database nowadays is very limiting.

-f
-- 
god?  i'm no god.  god has mercy.

Re: PostgreSQL 9.4: initdb: invalid locale settings

[opendaddy]

Hello,

On 21. januar 2015 at 8:26 PM, frantisek holop min...@obiit.org wrote:

LC_ALL is not supported yet, try LC_CTYPE.

$ sudo su - _postgresql
$ export LC_CTYPE=en_US.UTF-8
$ initdb -D /var/postgresql/data -U postgres -E UTF8 -A md5 -W
$ psql -U postgres -l

I couldn't get it to work with `LC_CTYPE`. It did, however, work with `initdb 
-D /var/postgresql/data/ --no-locale`.

O.D.

Re: PostgreSQL 9.4: initdb: invalid locale settings

[opendaddy]

On 21. januar 2015 at 8:44 PM, frantisek holop min...@obiit.org wrote:

you are not giving details, so i don't know.
but a non-utf8 database nowadays is very limiting.

Indeed, thanks for your example. I'm now rolling with `initdb -D 
/var/postgresql/data/ --no-locale -E UTF8`.

O.D.

Locale

[Matias Moreno Meringer]

Hi there.

I use mutt in a xterm to check my emails. I speak spanish, so have a
lot of emails in that language. Problem is because mutt doesn't
display regional character properly, neither others console based
applications (like emacs).

Can you point me to the right doc to check? Did a few searches, but
didn't find anything useful.

Tried to export some locale's variables, but without any luck.

Thanks in advance,
Matias.-
--

Re: Locale

[Peter Hessler]

export LC_CTYPE=en_US.UTF-8

in my .xinitrc / .xsession tells programs To Do The Right Thing.

Of course, not everything supports UTF8, so your milage may vary.

Mutt *does*, as does xterm, ssh, and tmux (my preferred combination for
reading mails).  If you want to write UTF8 chars and have them displayed
nicely in your terminal, you'll need to use vim / emacs / 3rd party util.
The built-in nvi and mg do not support displaying them (but mg does
allow you to write the chars).


On 2012 Dec 30 (Sun) at 12:42:30 -0300 (-0300), Matias Moreno Meringer wrote:
:Hi there.
:
:I use mutt in a xterm to check my emails. I speak spanish, so have a
:lot of emails in that language. Problem is because mutt doesn't
:display regional character properly, neither others console based
:applications (like emacs).
:
:Can you point me to the right doc to check? Did a few searches, but
:didn't find anything useful.
:
:Tried to export some locale's variables, but without any luck.
:
:Thanks in advance,
:Matias.-
:--
:

-- 
The porcupine with the sharpest quills gets stuck on a tree more often.

Re: Locale

[Matias Moreno Meringer]

Peter Hessler wrotes:
 export LC_CTYPE=en_US.UTF-8
 
 in my .xinitrc / .xsession tells programs To Do The Right Thing.
 
 Of course, not everything supports UTF8, so your milage may vary.

Was able to fix the problems exporting LC_CTYPE to es_ES.ISO8859-15. I
don't use X at all, so append it to ~/.profile.

I tried to export locale's variables to fix it, but wasn't able to get
it work. Problem was because I didn' know what names Openbsd uses for
locales. With your help, was able to find their definition in
/usr/share/locale (duh!).

Now it works fine for me.

Thanks for the help, Peter.

Regards,
Matias.-
--

Re: Locale

[Christian Weisgerber]

Peter Hessler phess...@theapt.org wrote:

 export LC_CTYPE=en_US.UTF-8
 in my .xinitrc / .xsession tells programs To Do The Right Thing.
 Of course, not everything supports UTF8, so your milage may vary.

If Matias is only concerned about Spanish, LC_CTYPE=en_US.ISO8859-1
might be better advice, in particular since vi(1) and mg(1) in base
can deal with single-byte character encodings, but not UTF-8.

And if somebody wants to understand what this character stuff is
all about, I recommend Jukka Korpela's A tutorial on character
code issues URL:http://www.cs.tut.fi/~jkorpela/chars.html.  Very
good, and far too long for anybody to read.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: Locale

[Stefan Sperling]

On Sun, Dec 30, 2012 at 12:42:30PM -0300, Matias Moreno Meringer wrote:
 Hi there.
 
 I use mutt in a xterm to check my emails. I speak spanish, so have a
 lot of emails in that language. Problem is because mutt doesn't
 display regional character properly, neither others console based
 applications (like emacs).
 
 Can you point me to the right doc to check? Did a few searches, but
 didn't find anything useful.
 
 Tried to export some locale's variables, but without any luck.
 
 Thanks in advance,
 Matias.-
 --

See http://www.openbsd.org/faq/faq10.html#locales

Re: 'ő' character doesn't get displayed in ls(1) output with UTF-8 locale

[LEVAI Daniel]

On Fri, Aug 12, 2011 at 21:48:48 +0400, Alexander Polakov wrote:
 2011/8/12, LEVAI Daniel l...@ecentrum.hu:
  Hi!
 
  I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
  I noticed that ls(1) won't display this one character (there are maybe
  more, I only noticed this one): 'E ' (nor its capitalized version: 'E ').
 
 ls doesn't support multibyte characters yet, try this:
 http://kerneltrap.org/mailarchive/openbsd-tech/2011/1/4/6887598

This works perfectly, thank You!


Daniel

-- 
LIVAI Daniel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D  650C C69B BE4C 83B6 3A8F

'ő' character doesn't get displayed in ls(1) output with UTF-8 locale

[LEVAI Daniel]

Hi!

I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
I noticed that ls(1) won't display this one character (there are maybe
more, I only noticed this one): 'E' (nor its capitalized version: 'E').


$ touch C6E
$ ls -1
C6
$ ls -1 |hexdump -C
  c3 b6 c5 91 0a|.|
0005
$ echo $LC_CTYPE
hu_HU.UTF-8

I can delete that file with `rm C6*`, and for example mc(1) can display
that two character filename fine.

Another thing I noticed is this:

$ ls -1 |iconv -f utf-8 -t latin2
C6C5


I don't know if this is relevant :\


Thanks,
Daniel


$ dmesg
OpenBSD 5.0 (GENERIC.MP) #44: Mon Aug  8 15:02:49 MDT 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM
real mem  = 2145775616 (2046MB)
avail mem = 2100596736 (2003MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/27/09, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS 
rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version 79ETE5WW (2.25 ) date 08/27/2009
bios0: LENOVO 2007FRG
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 93P5030 serial  2444 type LION oem SONY
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 
0xe/0x1!
cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03
ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: apic 1 int 16
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1400 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 1 int 16
drm0 at radeondrm0
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi
azalia0: codecs: Analog Devices AD1981HD, 0x/0x, using Analog Devices 
AD1981HD
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: msi, address 
00:16:41:aa:d2:70
ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21
pci3 at ppb2 bus 3
wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, 
address 00:18:de:65:2d:37
ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23
pci5 at ppb4 bus 12
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb5 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2
pci6 at ppb5 bus 21
cbb0 at pci6 dev 0 function 0 TI PCI1510 CardBus rev 0x00: apic 1 int 16
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
ichpcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02: 

Re: 'ő' character doesn't get displayed in ls(1) output with UTF-8 locale

[LEVAI Daniel]

On p, aug 12, 2011 at 16:22:17 +0200, LEVAI Daniel wrote:
 Hi!

 I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
 I noticed that ls(1) won't display this one character (there are maybe
 more, I only noticed this one): 'E' (nor its capitalized version: 'E').

Wow, it got messed up. I'll reproduce it, and will upload screenshots.


Daniel

--
LIVAI Daniel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D  650C C69B BE4C 83B6 3A8F

Re: 'ő' character doesn't get displayed in ls(1) output with UTF-8 locale

[Alexander Polakov]

2011/8/12, LEVAI Daniel l...@ecentrum.hu:
 Hi!

 I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
 I noticed that ls(1) won't display this one character (there are maybe
 more, I only noticed this one): 'E ' (nor its capitalized version: 'E ').

ls doesn't support multibyte characters yet, try this:
http://kerneltrap.org/mailarchive/openbsd-tech/2011/1/4/6887598

The bugs in wcwidth() mentioned later in the thread are now fixed, I think.

-- 
Alexander Polakov | plhk.ru

gvim ignoring non-ASCII input with UTF-8 locale

[Дмитрий Царьков]

Good [time of the day]!

My X11 is set up to have us and ru XKB layouts. When using browser
I get cyrillic chars as supposed to, but using gvim all non-ASCII
chars (either typed in or read from utf-8 encoded file) are replaced
with spanish (upside down) question marks.

As I have all my text data in UTF-8 and some of it has UTF-only chars,
I would like to understand, how can I get gvim to display them
properly.

-- 
Dmitrij D. Czarkoff

Re: gvim ignoring non-ASCII input with UTF-8 locale

[Tomas Bodzar]

With vim/gvim you can easily set your desired encoding.
$ gvim
:set encoding=utf-8

2010/6/15 PPP8QQP8P9 PP0QQP:PP2 czark...@gmail.com:
 Good [time of the day]!

 My X11 is set up to have us and ru XKB layouts. When using browser
 I get cyrillic chars as supposed to, but using gvim all non-ASCII
 chars (either typed in or read from utf-8 encoded file) are replaced
 with spanish (upside down) question marks.

 As I have all my text data in UTF-8 and some of it has UTF-only chars,
 I would like to understand, how can I get gvim to display them
 properly.

 --
 Dmitrij D. Czarkoff

UTF-8 and locale suppor

[Artur Litwinowicz]

Hello,
   I would like to ask about potential plans regarding UTF-8 in locales
support.
In details (now on my box runs 4.6 release) I am looking
in /usr/share/locale for xx_XX.UTF-8 but all catalogs with UTF-8 are
empty - current release is not supporting that encoding ?

   The problem starts when I am trying to create PostgreSQL cluster
with: --locale=pl_PL.UTF8 (cluster creation program says that there is
no locale support) - without that it is not possible to sort properly
data in SQL queries :(

Please let me know if any solution for this problem exists or in the
future that feature will be available :)

Best regards,
Artur

ps. OpenBSD is for me the BEST system on the World and I do not like
to use any other :)

locale support, again

[Toni Mueller]

Hi,

I know that the subject of what to do in the absense of having locale
support has been discussed quite often already.

I'd like to know what I need to do to supply full locale support to
applications that want to use them. My problem arises from those pesky
web applications which simply assume that such complete locale
support is present, and (try to) use it to format their output for the
user. Not having locale support means a lot of hacking, and/or
switching platforms, in every single case. Having it in the base
system, or maybe in an optional package like eg. 'miscXY.tgz', could
imho provide great relief for many users.

The theme has been recurring often enough to (imho) warrant making a
stab at it for 4.7, unless there are objections that I'm not aware of.


-- 
Kind regards,
--Toni++

Re: locale en_US.ASCII?

[ropers]

2009/7/27 Geoff g...@lib.oat.com:
 Is there a reason the en_US.ASCII locale is not available in
 the standard distribution?

Well, UTF-8 is backwards-compatible with US-ASCII. Or maybe when you
said US-ASCII you were really thinking of ye olde Code Page 437?
http://en.wikipedia.org/wiki/Code_page_437

That said, It is my understanding that Unicode support in OpenBSD
hasn't been completed yet (correct me if I'm wrong).

--ropers

Re: locale en_US.ASCII?

[Geoff]

From rop...@gmail.com  Mon Jul 27 10:07:03 2009
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com 
[209.85.220.215])
by lib.oat.com (8.14.3/8.14.3) with ESMTP id n6RE6wFn018594
for g...@lib.oat.com; Mon, 27 Jul 2009 10:07:02 -0400 (EDT)
Received: by fxm11 with SMTP id 11so2735613fxm.18
for g...@lib.oat.com; Mon, 27 Jul 2009 07:06:52 -0700 (PDT)
Received: by 10.204.70.19 with SMTP id b19mr3168590bkj.62.1248703612472; Mon, 
27 Jul 2009 07:06:52 -0700 (PDT)
Subject: Re: locale en_US.ASCII?
To: Geoff g...@lib.oat.com
Cc: misc@openbsd.org

2009/7/27 Geoff g...@lib.oat.com:
 Is there a reason the en_US.ASCII locale is not available in
 the standard distribution?

on Mon, 27 Jul 2009 16:06:52 +0200 ropers rop...@gmail.com wrote:
Well, UTF-8 is backwards-compatible with US-ASCII. Or maybe when you
said US-ASCII you were really thinking of ye olde Code Page 437?
http://en.wikipedia.org/wiki/Code_page_437

No, I'm thinking about 0x20 (space) to 0x7E with upper
and lower case ABCDEFGHIJKLMNOPQRSTUVWXYZ, 0123456789,
and the US ASCII punctuation from 0x21 - 0x2F and 0x7B - 0x7E.
That is the common character set for keyboard input
and printable output across all the systems I use.
If all my keyboards, displays, and listing printers used a
consistent ISO8859-1 set (for example), there wouldn't be
much of a problem.

I need to be able to compose  edit text-like data for a
number of systems which use various character sets.
I need to be able to prepare that data in a consistent
manner logged into an OpenBSD system from these systems.

The printers and other specialized I/O devices
producing and consuming my data map 8-bit codes to glyphs
in different ways: mostly nonstandard or obscure.
Worse, many of them have multiple mappings available.

If I set the locale to C, most systems define
the characters from 0x7F-0xFF as not printable.
Editors, etc, print them as some sort of escaped or hex
representation which is consistent and I can enter the
values as hex or octal.  (n)VI, for instance, shows
characters as backslash  2 hex digits,
and inputs them as control-X  2 hex digits.

The problem is that UTF-8 is a superset of US-ASCII.
Various implementations differ incompatibly on how to handle the
characters not in US-ASCII, even when supposedly set to the
same locale:
   glyphs are missing from fonts
   glyphs are inconsistent from system to system
   characters are printed as (character-0x80)
   etc.
Input encoding from keyboards often also changes.

Since the OpenBSD default C locale defines many of the
characters 0x7F-0xFF as printable, my local systems attempt
to print the characters in ways that are often not visible
or readable.

I understand that many people don't have US-ASCII keyboards
or displays and find the limitation to that character set
a problem. Still, the ability to map character/byte/octet
values to and from visible marks in a completely consistent
manner is valuable to me and perhaps to other people as well.

That said, It is my understanding that Unicode support in OpenBSD
hasn't been completed yet (correct me if I'm wrong).

I don't believe it is there as well, since I haven't
seen wchar typed data in sources very often.

That's (selfishly) fine for me.
Living in a US-English environment shields me from a lot
of the need for conversion.

Unicode is an extremely unpleasant thing I'm avoiding until
the worth of the outcome exceeds the pain of conversion.
For instance, will the world settle on a compressed form
using the escape convention or will all data change to 16-bit?
Or both?

Legacy hardware, programs and data have a way of living forever.
Translation to and from Unicode will be with us for a
very long time even when the common systems and programs
are all Unicode-aware. :-( :-( :-(

geoff steckel

Re: locale en_US.ASCII?

[ropers]

2009/7/27 Geoff g...@lib.oat.com:
 No, I'm thinking about 0x20 (space) to 0x7E with upper
 and lower case ABCDEFGHIJKLMNOPQRSTUVWXYZ, 0123456789,
 and the US ASCII punctuation from 0x21 - 0x2F and 0x7B - 0x7E.
 That is the common character set for keyboard input
 and printable output across all the systems I use.

 I understand that many people don't have US-ASCII keyboards
 or displays and find the limitation to that character set
 a problem. Still, the ability to map character/byte/octet
 values to and from visible marks in a completely consistent
 manner is valuable to me and perhaps to other people as well.

 Unicode is an extremely unpleasant thing I'm avoiding until
 the worth of the outcome exceeds the pain of conversion.
 For instance, will the world settle on a compressed form
 using the escape convention or will all data change to 16-bit?
 Or both?

Read this: http://en.wikipedia.org/wiki/UTF-8#Description

UTF-8 is 8 bit for the US-ASCII-compatible characters. Anything beyond
that, it's 2, 3, 4 byte per character. But as long as that upmost bit
is zero, you're looking at a completely US-ASCII compatible single
byte character. The 16+ bit characters only start where that upmost
bit is no longer zero.

Btw., in the first table currently shown at that link (have I talked
about this before?), the underlined parts in the example cells are
just to illustrate which parts of the hexadecimal Unicode code points
correspond to which bits in the binary representation on the following
line.

But this is probably getting OT, because AFAIK UTF-8 support isn't in
OpenBSD yet...

regards,
--ropers

locale en_US.ASCII?

[Geoff]

If this has been discussed somewhere before, just tell me
where to search - it doesn't come up in the archives of
the misc, etc. mailing lists...

Because I work from a number of locations and computers which
have inconsistent ideas of what UTF-8, ISO8859-1, etc. mean for
character codes above 0x7E, I'd like to be able to set my
LOCALE to a 7-bit one so that vi, etc. will not try to display
something which will probably be confusing or inconsistent.

I noticed that the default ctype_.c is not a C 7-bit locale but
something resembling 8859-1, and that the file
.../src/share/locale/ctype/en_US.ASCII.src is not normally
compiled by the Makefile.

Is there a reason the en_US.ASCII locale is not available in
the standard distribution?

As an aside, many other unix-like, BSD-derived, or other POSIX-like
implementations default to a 7-bit C locale.
Since many developers are in non-US locations, I can believe that
it's more convenient to set the default isprint() functionality
to call many 8-bit characters printable.
I can't find anything in the C standard which requires either behavior.
POSIX does specify that the C locale defines a portable 7-bit set
of characters as printable.
It would perhaps be a little less surprising if OpenBSD supplied
a 7-bit C locale and set the default login locale to an 8859-1
one, but there are probably good reasons not to do it that way.

Thanks for any information!
   geoff steckel

Re: Locale

[Bibby]

Hi, Toine.

May be you can contact Marc Espie(espie#openbsd.org), he said locale support
was in his todo list.

I need Chinese locale support too. ^_~
-- 
Michael Bibby, China.

Locale

[Toine Boven, van]

Hi there,
Is there any chance that OpenBSD gets Locale support?
I've seen some hacks using Linux-compatablity support, but it would be a lot
nicer if it would be available in the standard install.
Is there anybody out there that can fix this?
I would like to have OpenBSD run my little secure webserver, but because of
the lack of Locale support, I can only serve english webpages using a CMS
because of the displaying of dates.
So now I'm forced to use FreeBSD, and I'm not likeing it!
Can someone help?

gr
Toine
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

OpenBSD 4.1 X.org and locale problem

[Szymon Nowak]

In last week I checked OpenBSD 4.1 from snapshot ane when I run xterm
   
  xterm -ls -fn -*-fixed-medium-*-*-*-*-130-*-*-*-*-iso8859-2
   
  I have in .profile 
   
  LANG=pl_PL.ISO8859-2
  export=LANG
  LC_ALL=pl_PL.ISO8859-2
  export LC_ALL
   
  xterm tell me 
   
  Locale not supported by Xlib locale set to C   
   
  What it is ? 
   
  In OpenBSD 3.9/4.0 i have not this messages and polish keyboard works fine 

 
-
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel 
bargains.

need help for chinese locale

[zuo lei]

yes, we want to build our own chinese locale

before starting our plan . we need your advice and your experience

email me please!

setting locale on terminal

[Vim Visual]

Hi,

from my recent emails you have probably guessed that I am jumping from
a debian system (have been GNU/Linux user for about ten years) into
the -wonderful- world of o'bsd (4.0) on an i386.

I am using for that the man pages, the absolute o'bsd book (which is
strangely nice to read, i would have never thought anything like that
of an informatics book) and the unofficial faqs.

I am almost done with the migration and very happy. I still have to
understand _correctly_ pf, of course.

However there's something that annoys me a lot: locale

In my zshrc I have set

export LC_NUMERIC=C
export LC_ALL=ca_ES.ISO8859-1
export LC_CTYPE=ca_ES.ISO8859-1

This worked perfectly on the debian system

My mother tongue is Catalan and I would like my system to be set up to
that language. It seems that for instance date is not behaving the
way I would like (it's in English) and also perl is complaining all
the time:

-
melanos| perl -v
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LC_ALL = ca_ES.ISO8859-1,
   LC_NUMERIC = C,
   LC_CTYPE = ca_ES.ISO8859-1,
   LANG = ca_ES.ISO8859-1
   are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).

This is perl, v5.8.8 built for i386-openbsd
-

This is very annoying because a number of things a written in perl;
e.g. pkg_add, etc

If I have a look at /usr/share/locale I find

melanos| ls /usr/share/locale | grep ca
ca_ES.ISO8859-1
ca_ES.ISO8859-15

I.e. they *exist*

Now; on a debian system I'd do the following:

dpkg-reconfigure localeconf and then als root set-language-env -E, or
something similar

What should I do in o'bsd? Any hint?

The gnome X enviroment recognizes my  /etc/profile though, which is set to

export LANG=ca_ES.ISO8859-15

All X programmes are in Catalan...

But I need the terminal in Catalan!

I have thousands of scripts which I'd have to modify because the
output of things like date are now different...

Thanks,

Pau

Problems with UTF-8 locale/filenames

[Benjamin Braatz]

Hello list!

I'm kind of new to OpenBSD (TZ=UTC last | tail -n 1: wtmp begins Wed  
Sep 28 12:06 2005).
(I played with FreeBSD for the last couple of weeks after abandoning  
Gentoo Linux, which

I used the last years, though.)

Since I believe in UTF-8/Unicode being the encoding scheme of the  
future, and because I
want to sync with my iBook, which already uses UTF-8-filenames, over  
ssh/rsync, I tried to

use the brand new LC_CTYPE support in OpenBSD 3.8-current.

Because there was no UTF-8 LC_CTYPE file in /usr/share/locale/ 
en_US.UTF-8 I created

one with mklocale and a source file stolen from NetBSD:
ftp ftp://ftp.netbsd.org//pub/NetBSD/NetBSD-current/src/share/locale/ 
ctype/en_US.UTF-8.src

mklocale  en_US.UTF-8.src  /usr/share/locale/en_US.UTF-8/LC_CTYPE

For the xterm I added the following to my .Xresources:
XTerm*vt100.utf8Fonts.font: -adobe-courier-medium-r- 
normal--17-120-100-100-m-100-iso10646-1

XTerm*vt100.locale: true
XTerm*vt100.utf8: 2

And then it mostly worked: I can create files with umlauts, accents,  
Cedillas, ... with bash

in xterm and they are displayed correctly, but:

1.) The input buffer (or whatever it is called) of bash command lines  
is not in sync with
the display, i.e. when I type one of the characters, which is encoded  
as 2 bytes in UTF-8,
I have to backspace two times to completely delete it from the  
buffer, which deletes an
extra character from the display, but this character stays in the  
buffer. The same is true

for csh.
ksh doesn't even accept umlauts and sh interprets them as some weird  
commands.
Does anyone know, what I could do to resolve this? I don't really  
know, if xterm or the

shells should be responsible, and hence, where I would have to look.

2.) When I'm on the console nothing of it works, since the console  
keyboard and screen

drivers do not know about UTF-8.
Is there anything I can do to make them convert my keystrokes to  
UTF-8 instead of ...

(Is it ISO 8859-1?) and convert output back again?
I did not find anything in man wsconsctl.conf. Does the kernel need  
to be hacked for
this to work? Is something in that direction planned for the (not too  
far) future?


3.) Another minor annoyance is, that the column calculation of ls is  
broken, when two-
byte-characters are present: Since it uses the fts_namelen field of  
the FTSENT structure
from /usr/src/include/fts.h, which in turn is computed by strlen()  
in /usr/src/lib/libc/gen/fts.c,
it calculates wrong widths, because strlen() counts bytes not  
characters.

 http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod
suggests to use mbstowcs() from stdlib.h instead of strlen() and  
mbstowcs() is already

implemented in /usr/src/lib/libc/locale/multibyte_sb.c.
Do you think I should file a PR about this? I'm just asking, because  
I do not want to annoy

too much by adopting this stuff so early.

Any hints, discussions, solutions on this matter are very welcome!
Thanks in advance!

Regards,
sean

--
Benjamin Braatz
[EMAIL PROTECTED]
Please reply also to my mail-address,
because I only read the daily digest.