Re: emacs misbehaves without --unibyte

[Paul Stoeber]

On Wed, May 29, 2002 at 09:23:11AM +0300, Eli Zaretskii wrote:
> > I started this thread because default emacs wouldn't let me navigate
> > filesystems that contain funny filenames, so the "8-bit cleanness"
> > discussion only applies to file name handling (although I had also
> > mentioned "text/binary files" in a general statement).
> 
> For that, Miles gave the solution: you should set up your language 
> environment correctly, or set file-name-coding-system explicitly.

Yes.  If you simply want to use dired as a robust filesystem browser
(like bash, only more comfortable), regardless of your language
or the language of who created the files, then

        (setq file-name-coding-system 'no-conversion)

seems to be a solution.  It works in the real life cases I've tried,
but will stop working if someone chooses to put a newline in a name.

> Please remember that Emacs decides where a file 
> name starts and ends in the Dired buffer by using a set of convoluted 
> regexps designed to parse the "ls -la" output for file's name, date, 
> time, attributes, etc.  A stray 8-bit byte can cause spurious wrong 
> matches of those regexps, and the net effect is what you reported.

"ls -la"'s output is made for users' eyes and trying to use it
as a back-end sacrifices total robustness.

I once had the same problem with smbclient.  I wanted to use it in a script,
but didn't want to sacrifice any robustness.  So I added a --batch-ouput
option, which was really effortless because all the data was at hand in the
C code, it was just a matter of changing the `printf's.  I made the output
so that it was (a) unambiguous and (b) easy to parse.  And the script
has been performing nicely without any glitches ever since.

Maybe that's not an option for Emacs because it wants to use whatever
/bin/ls is available on the system.