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

[Miles Bader]

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

> Dave Love <address@hidden> writes:
> > It seems more useful to count in characters (assuming they're
> > decodable), but the problem remains that it's now broken on current
> > systems.

Why is it more useful to count in characters?

Of course that makes things a bit simpler for emacs, but counting in
bytes has the advantage that a tool doesn't have to be support the
coding system ls does in order to grab the filenames.  Since it seems
easier for a `smart' (coding-system aware) tool like emacs to act
`dumb', than for a dumb tool to act smart, that suggest to me that it's
better to use the dumb method (byte counts).

Of course I suppose you could just argue that --dired is for emacs'
use, and should just do whatever it the most convenient for emacs.

[actually, does ls itself even know the actual character counts, or is
it just regurgitating binary chunks that it doesn't interpret?]

> > If there are incompatible versions of ls, I think you have
> > to check `ls --version' to decide what to do.
> 
> I don't know the relation of "ls (coreutils)" and "ls
> (fileutils)".  Does anyone know how to detect a buggy "ls"?

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.

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo