Kenichi Handa <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
