[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dired doesn't work properly with a multibyte locale

From: Kenichi Handa
Subject: Re: dired doesn't work properly with a multibyte locale
Date: Mon, 3 Feb 2003 11:11:32 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, Miles Bader <address@hidden> writes:
> Kenichi Handa <address@hidden> writes:
>>  > I just checked, 4.1 has already all support.  Sorry for confusion.
>>  I see.  But, anyway, "ls (coreutils) 4.5.4" has a bug.  If
>>  this version of "ls" is already widely spread, shouldn't
>>  Emacs pay special attention to such a buggy "ls"?

> Is it worth the trouble?  As far as I know the problem only occurs with
> newlines in filenames, which is an extremely rare thing; as long as it
> gets fixed in the next version, that seems good enough to me...

If the bug happens only for such filenames, I agree that
it's not worth working on it anymore.


Andreas Schwab <address@hidden> writes:
> Here is a patch.  The dired offset are documented as being byte counts,
> not character counts.  The bug happens in any multibyte locale.

This statement reads that any character encoded by multiple
bytes in a filename causes a trouble, for instance any CJK
characters in CJK locales or any non-ASCII chars in UTF-8
locale.  As you can use ja_JP.eucJP locale, could you please
try some Japanese file name?

> coreutils is just a merge of fileutils + shutils + ...

> The NEWS file for coreutils says:

>    [4.5.1]
>      ...
>      This package is the union of the following:
>      textutils-2.1, fileutils-4.1.11, sh-utils-2.0.15.

Hmmm, then, it's strange that "ls (fileutils) 4.1" works,
but "ls (coreutils) 4.5" doesn't.

Ken'ichi HANDA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]