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

[Kenichi Handa <handa@m17n.org>]

In article <buoptqarwax.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
> Kenichi Handa <handa@m17n.org> 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.

But...

Andreas Schwab <schwab@suse.de> 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
handa@m17n.org