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

[Miles Bader]

Kenichi Handa <address@hidden> writes:
> > If there's a file containing a newline, then if LANG=C, dired can
> > correctly deal with it (e.g., I can put the cursor on it and hit RET,
> > and it visits that file), but if LANG=ja_JP.eucjp, then it correctly
> > displays all _other_ files, but you can't use RET to visit the
> > newline-in-the-file-name file (it says `File no longer exists; type `g'
> > to update Dired buffer').
> 
> So, I have no idea what's wrong with the current code.
> Could you debug it?

Hmm, it actually seems to be a bug with `ls'!

I created two files, one called `abc\ndef' (where \n is a newline), and
one called `1234567'.  Here's what ls prints if stdout is a tty (I've
indented the output by 3 spaces):

   (tmp) LANG=ja_JP.eucJP ls -l --dired abc* 123*
     -rw-rw----    1 miles           6 2003-01-27 13:03 1234567
     -rw-rw----    1 miles           6 2003-01-27 12:58 abc?def
   //DIRED// 53 60 114 121
   //DIRED-OPTIONS// --quoting-style=literal

[note that the start/end offsets of each filename differ by 7]

But here's what the _same_ command prints if stdout is a pipe (which I
presume is the case for dired):

   (tmp) LANG=ja_JP.eucJP ls -l --dired abc* 123* | cat
     -rw-rw----    1 miles           6 2003-01-27 13:03 1234567
     -rw-rw----    1 miles           6 2003-01-27 12:58 abc
   def
   //DIRED// 53 60 114 120
   //DIRED-OPTIONS// --quoting-style=literal

Now the start/end offsets of `abc\ndef' now only differ by 6 (which is
obviously wrong, since the filename is 7 characters long)!  Morever
this problem only seems to occur if LANG=ja_JP.eucJP, _not_ if LANG=C.

My ls --version says:  ls (coreutils) 4.5.4
What version do you have?

I guess I'll report a bug against ls...

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen