DragonFlyBSD

:New submission from Simon 'corecode' Schubert <corecode@fs.ei.tum.de>:
:
:mount_msdos is compiled static, so it needs to be linked explicitly to the
:citrus libs to be able to use certain locales.
:
:----------
:messages: 2579
:nosy: corecode
:priority: bug
:status: unread
:title: mount_msdos needs to link to citrus libs
:
:_____________________________________________________
:DragonFly issue tracker <bugs@lists.dragonflybsd.org>

I dunno.  I'd prefer that the binaries in /bin and /sbin generally
    not be linked against citrus.  It's a lot of bloat for no good reason.

-Matt

How do you propose dealing with file names that don't use ASCII characters then?

:> I dunno. I'd prefer that the binaries in /bin and /sbin generally
:> not be linked against citrus. It's a lot of bloat for no good reason.
:
:How do you propose dealing with file names that don't use ASCII characters then?

What does that have to do with mount_msdos?  All file names devolve into
    a string of 8 bit characters.  If your shell allows you to specify them
    as arguments mount_msdos won't know or care that they aren't ascii.

Is there a specific problem that needs to be solved by linking it that
    would not also require linking every program in /bin or /sbin against
    citrus?  Because I really, really do not want to link every program
    in /bin or /sbin against citrus... it would bloat those binaries
    considerably and I am not going to allow them to be dynamically linked,
    even if some of the other BSD dists have switched to dynamic linking
    for binaries in the root filesystem.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Is this why DragonFly is just about the only modern operating system that
still can't show international characters in ls and such?

Hi there,

I don't know enough to participate in this thread, but I would like
to understand the problem. Can you give examples of other BSD's
which do behave the way you want with 'ls' or similar command-line
utilities?

I thought this was because we dont have UTF-8 support in the console...i
maybe wrong though.

On Wed, 25 Apr 2007 19:37:21 -0700
Fearow <lists@spearow.com> wrote:

No that is caused by -q being the default when the output is a
terminal, try using echo in a directory with international characters in
the filename or redirecting the output of ls eg:

$ls | cat
ic
list
ïòðå

International characters are not control characters. FreeBSD and all the linux
distros to which I have access can handle this.

All using ko_KR.UTF-8 locale. If Korean characters are seen as control
characters in this locale, there is something wrong.

FreeBSD/Linux:
$ touch 잠자리
$ ls
./ ../ 잠자리
$ ls -q
./ ../ 잠자리

DragonFly:
$ touch 잠자리
$ ls
?????
$ ls | cat
잠자리

For the C locale, they are non-graphical characters. That's why they are
not printed.

Joerg

This is why I ask if this refusal to make /bin dynamic and/or link anything
there against citrus is why ls and such in DragonFly aren't able to handle
locales while this has worked fine in other operating systems for years.
RedHat 7.3 supported this! This is a showstopper for shell servers with
international users.

It's not. Change the locale env settings on your DragonFly system from
'C' to 'ko_KR.UTF-8'. As Joerg said, by default, it's 'C'.

'locale' on those other systems are already set to ko_KR.utf8 or similar -
make DragonFly match and you should get the expected behavior.

The one thing I can think of is that there isn't a locale setting in the
DragonFly installer, so 'C' gets picked by default.

1. locale
   LANG=""
   LC_CTYPE="C"
   LC_COLLATE="C"
   LC_TIME="C"
   LC_NUMERIC="C"
   LC_MONETARY="C"
   LC_MESSAGES="C"
   LC_ALL=""

1. 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=

We first should evaluate how much bloat it adds and maybe add a build time
flag to select the citrus locales the user wants to add. It's just crucial
for non-US people with funny characters.

cheers
simon

polachok and I agreed that we should link /bin with a basic set of locales,
which is configurable by the user on buildworld time.

I think that UTF-8 should be the default (single default), but I'm open which
other locales should be added (Windows? Latin9?)

The alternative would be to implement a loader which can load and link citrus
modules at runtime into a static binary, but this seems way too complicated.

committed.