redirection of "ls" command to file gives chaotic content
 

When I want to save the output of the "ls" command I do
this:
ls > file.txt
but when I try to read the resulting file with "less" it
says
"file.txt" may be a binary file: See it anyway?
and if I reply with yes the file contains ESC[0m or some
other similar garbage at the beginning and end of every
line. I have searched using Google and have not figured
out how to work around this weirdness. I shelled into
another computer running SUSE 11 and it did the same thing.
I have used the ls command like this many times in the past
and never ran into this until lately. Can somebody point
me in the right direction to fix this? Thanks.

Your ls command probably has "--color=always" aliased to it. That's what the esc sequences are--ascii color codes.

If you set the alias to "--color=auto" it won't send the codes through pipes or redirects, but then you'll also lose color when you pipe it into less or such.

You can bypass the alias and use the original ls command directly by either backslashing the command "\ls" or enclosing it in quotes.

Edit: Oh, and it looks like less is complaining because you don't have color code support enabled for it either. Alias less to "less -R" and it will interpret and display your piped results in color (assuming the input program is sending the codes).

Wow, thanks. I did "alias ls=ls" and it works fine. Your
information is VERY helpful, just can't thank you enough.

I suspected that would be the problem as soon as I saw the title of your question. :)

Incidentally you can also use "unalias ls" to unset it for that terminal. Of course it will only be temporary unless you remove or alter the line in your bash startup scripts that sets it in the first place. But I generally find it easier to just backslash-escape the command when I need to than to alter or unset it and have to reset it again later.


P.S: Another major program that has optional color support is grep.