mount_msdos needs to link to citrus libs
mount_msdos is compiled static, so it needs to be linked explicitly to the
citrus libs to be able to use certain locales.
#1 Updated by dillon almost 11 years ago
:New submission from Simon 'corecode' Schubert <email@example.com>:
:mount_msdos is compiled static, so it needs to be linked explicitly to the
:citrus libs to be able to use certain locales.
:title: mount_msdos needs to link to citrus libs
:DragonFly issue tracker <firstname.lastname@example.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.
#3 Updated by dillon almost 11 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.
#7 Updated by steve almost 11 years ago
On Wed, 25 Apr 2007 19:37:21 -0700
Fearow <email@example.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
#8 Updated by lists almost 11 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.
$ touch 잠자리
./ ../ 잠자리
$ ls -q
./ ../ 잠자리
$ touch 잠자리
$ ls | cat
#10 Updated by lists almost 11 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
#11 Updated by justin almost 11 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.
#13 Updated by corecode over 8 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.