Piping the output of comand columns

Expanding on @dessert's answer, you need a bit more work to make your colored ls version behave just like the real ls in (hopefully?) all cases. The problem is that ls is not meant to be parsed but intended for human eyes only. For that purpose, it strongly adapts how it works depending on the environment, e.g. whether it is connected to a terminal or outputting to a pipe.

First, you don't need a separate /bin/lsslss executable to avoid recursion. Use the shell built-in command to call an executable from the disk, ignoring any shell functions or aliases of the same name.

Second, $* gives you all function arguments as a single string, which is then subject to word-splitting because it is unquoted. This can give surprisingly wrong results if you have arguments with spaces. Always use "$@", which exactly preserves all arguments as they were originally given, with no concatenation or further splitting.

And third, depending on where you put the definition, the syntax ls () { ... ;} to define a function might not work if ls is already an alias, because alias expansion happens first, causing a syntax error. Use the explicit syntax by writing function before it.

Then, we can use ls' -C flag to manually enable column output:

function ls() { command ls -C "$@" | lolcat ;}

However, if we just do that and pipe the output through lolcat (or anything else), you will notice that it doesn't use the full width of your terminal any more, but only 80 columns at most. This is because it can not detect the terminal width if its standard out is no longer directly connected to it. Your shell still knows the terminal though, and it populates the COLUMNS variable with the width it detected. But, as this variable is not exported by default, ls does not see this value. We can manually pass it on just for this command like:

function ls() { COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ;}

Now we should always get the correct width, but what happens if we really want to pipe ls through something else? Normally you shouldn't do that, because as I said in the beginning, ls should never be parsed. Sometimes it might still be useful though (and some scripts might sadly rely on it), so let's try to at least preserve the original behaviour then. Right now, we would always get the columns as output for e.g. ls | cat. (It's not colored any more there because lolcat also checks if it outputs to a terminal or pipe and switches colors off in the latter case)

Let's add a check to our function that uses the plain real ls if it is piped and our fancy rainbow column version only for terminal view. Whether standard out (file descriptor 1) is a terminal/TTY can simply be checked with [[ -t 1 ]]:

function ls() { 
    if [[ -t 1 ]] ; then COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ; else command ls "$@" ; fi
}

I think that should suffice to catch all cases where special/different behaviour from ls is expected, so that your function only adds color when viewed directly in a terminal and otherwise does not alter anything.

When its output is piped, ls disables the column listing. Use the -C option to explicitly enable it:

ls(){ COLUMNS="$COLUMNS" command ls -C "$@" | lolcat; }

COLUMNS="$COLUMNS" sets the COLUMNS variable correctly to the current terminal’s width, without that it defaults to 80 – try resizing your terminal window and compare the outputs. command ls serves to ignore aliases and functions and call ls wherever its executable is. Note that I used "$@", to quote the Bash Hackers Wiki:

["$@"] reflects all positional parameters as they were set initially and passed to the script or function. If you want to re-use your positional parameters to call another program (for example in a wrapper-script), then this is the choice for you, use double quoted "$@".
Well, let's just say: You almost always want a quoted "$@"!