Bug #612

mount_msdos needs to link to citrus libs

Added by corecode over 7 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:corecode% Done:

0%

Category:-
Target version:-

Description

mount_msdos is compiled static, so it needs to be linked explicitly to the
citrus libs to be able to use certain locales.

History

#1 Updated by dillon over 7 years ago

:New submission from Simon 'corecode' Schubert <>:
:
: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 <>

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

#2 Updated by trevorjkendall over 7 years ago

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

#3 Updated by dillon over 7 years ago

:> 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
<>

#4 Updated by lists over 7 years ago

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

#5 Updated by wa1ter over 7 years ago

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?

#6 Updated by elekktretterr over 7 years ago

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

#7 Updated by steve over 7 years ago

On Wed, 25 Apr 2007 19:37:21 -0700
Fearow <> 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
ïòðå

#8 Updated by lists over 7 years ago

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
잠자리

#9 Updated by joerg over 7 years ago

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

Joerg

#10 Updated by lists over 7 years ago

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.

#11 Updated by justin over 7 years ago

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.

(DragonFly system)
# locale
LANG=""
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=""

(RedHat ES4)
# 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=

#12 Updated by corecode over 7 years ago

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

#13 Updated by corecode over 5 years ago

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.

#14 Updated by polachok over 5 years ago

committed.

Also available in: Atom PDF