5

I am using lolcat to get the output of ls in color. To do this i have copied /usr/bin/ls to /usr/bin/lsslss (to avoid an endless loop since alias cannot acccept $* or $@) and I have added the function:

ls(){ lsslss $* | lolcat; } to .bashrc

The issue is that when i use ls the pipe is piped each file at a time so it shows up as a long list like this:

enter image description here

instead of a table like this:

enter image description here

to change it into a table I can pipe the output into columns command. but when I do it changes back into a long list (probably because of columns only formats it instead of changing it into rows)

I was originally going to do:

ls(){ lsslss $* | columns | lolcat; }

Anyway I was wondering is there a way to pipe the raw output instead of using | to be able to pipe the output of columns into lolcat?

Thanks in advance. Sorry if my question is badly worded or hard to understand. I almost always find the questions already asked so I dont post questions often.

14

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.

  • Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right. – cohill Oniell May 20 at 12:11
  • That is going beyond the call of duty! – TRiG May 20 at 18:21
4

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 "$@"!

  • 1
    You might want to export the shell's COLUMNS variable first, so that ls can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding /bin/ls you can also command ls to force an executable file lookup, ignoring shell functions/aliases. – Byte Commander May 20 at 11:14
  • 1
    Hmm, actually... there's even more stuff needed to not break things. ls is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer. – Byte Commander May 20 at 11:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.