Support for -l / --long about colorls HOT 8 CLOSED

Fixed with PR #63. Closing this issue now. Good work, @GladOSkar 👍

from colorls.

I think the information provided by -l / --list is really helpful, e.g., file permission, file size (when combined with -h / --human-readable) and the symlink destination.

from colorls.

Hmm, not sure how well it fits in with the other flags. But, it'd definitely fit well as a stand-alone flag.

If anyone likes to work on this issue, please refer to this approach (psuedocode-ish) I haveve in my mind. 😄

output = `ls -l #{input}`
arrays = output.split("\n").map { |line| line.split(' ') }

puts arrays.map do |line|
   line.map do |word|
       # check if word is a file / directory
       # and change it appropriately
       # with (color + icon) or just white.
   end.join("\t")
end.join("\n")

from colorls.

I would like to work on this.
I am no expert in ruby but rather than parsing ls (which is apparently discouraged) i would recommend printing all info from File.stat(@input) since it is all given there.
What do you think?
e.g. stat.mode \t stat.nlink \t Etc.getpwuid(stat.uid).name \t Etc.getpwuid(stat.uid).name \t Etc.getgrgid(stat.gid).name \t Filesize.from("#{stat.size} B").pretty \t stat.mtime \t filename \n
Where stat.mode needs to be prettyfied of course

from colorls.

Hey @allenye0119! Thanks for filing this issue. If this is required, the only way might be to workaround by parsing the output of ls -l using backticks in Ruby (or similar system calls). Keeping this in mind, do you think -l / --list flag needs to be supported?

from colorls.

I think this was debated at the very start as well. Initially, lc -l was supported, relevant discussion at #4

from colorls.

@GladOSkar - Yes, I knew that ls parsing is a discouraged approach. But, I wasn't aware of File#stat method. Sure, go ahead with it. I'm assigning this to you. 😄

from colorls.

+1

from colorls.