Earlier quoted context omitted.
This works with sorting, and it's easier to pick big files out at a glance. I would use this as often as -h
You could also use 'ls -lh | sort -h'.
Hacking ls -l
61–70 of 93 posts
Re: Hacking ls -l
#62While I appreciate the story, what's wrong with `ls -lh`?
I guess people can be very different in this respect. I really need the full number (or at least all of the numbers in the same unit) to be displayed. I don't find the 'human' format helpful at all when looking at ls output.
Re: Hacking ls -l
#63Earlier quoted context omitted.
For me, -h makes it more difficult to quickly compare the sizes of files in one list by glance. This is something that I have to do often enough that it has prevented me from adding -h to my ls alias. I'd have to use it for a bit to be sure, but the post's suggestion seems a pretty good 'best of both worlds' solution to me.
This. I run into the situation more often with 'du' (when trying to find which subdirectory tree has excess junk in it), to the point that, while 'du -h' is human readable, it's not particularly sortable so: du -hs $( du -s * | sort -k1nr,1 -k2 | head ) .... which will return the human-readable output, based on numerically sorting the full numeric output. Eyeball comparisons are easier as you're aware that results ar…
du -h | sort -h
And get properly size-sorted output.
Re: Hacking ls -l
#64Incidentially, I completed ls's set of -a-z options recently. http://joeyh.name/~joey/blog/entry/ls:_the_missing_options/ (Well, actually, I never got around to writing -z, but it's clear what it should do, and any ls hackers are encouraged to finish that up.)
Your link is broken, FYI
Re: Hacking ls -l
#65Most annoying is that gcc warns about perfectly valid and logical code. That causes people to ignore warnings, and before you know it, you have a piece of software that has more warnings than lines of code. Alternatively, when you cleverly figure out how to work around the warning, like the author does, you now prevent that rule from triggering even when it's right. Clearly a better unit test is needed.
That warning seems like a nasty hack anyway, if the compiler can't inline a local when running safety checks. It is super scary that the compiler appears to be using a different constant from printf for its format checker, that shows it probably isn't using a pattern supplied by printf.
(Or they did that and it's just a bug somewhere.)
Re: Hacking ls -l
#66Most annoying is that gcc warns about perfectly valid and logical code. That causes people to ignore warnings, and before you know it, you have a piece of software that has more warnings than lines of code. Alternatively, when you cleverly figure out how to work around the warning, like the author does, you now prevent that rule from triggering even when it's right. Clearly a better unit test is needed.
Consider that the compiler generating that warning knows only Standard C, and in fact you could be pairing it with any C library, including those that are strictly conforming and don't support the ' extension.
Re: Hacking ls -l
#67Re: Hacking ls -l
#68Most annoying is that gcc warns about perfectly valid and logical code. That causes people to ignore warnings, and before you know it, you have a piece of software that has more warnings than lines of code. Alternatively, when you cleverly figure out how to work around the warning, like the author does, you now prevent that rule from triggering even when it's right. Clearly a better unit test is needed.
The printf ' format specifier is not Standard C. It's in neither the C99 Standard nor the new C11 Standard. So it's not actually valid, and it's a coincidence if it happens to work with your Standard Library. Consider that the compiler generating that warning knows only Standard C, and in fact you could be pairing it with any C library, including those that are strictly conforming and don't support the ' extension.
(In the example, he's compiling ls with the -std=gnu99 flag, which means he's targeting GNU, not C99 or C90 or C11 or POSIX or any other standard.)
Re: Hacking ls -l
#69Re: Hacking ls -l
#70Earlier quoted context omitted.
It is not very easy because it is an unusual request. But I still wonder if this is easier than ls -l | sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1,\2/;ta' ?? The investigations would be interesting it they were more complete, i.e. if the actual result was a change in the locale which could be appliable to other tools printing numbers besides ls (in the author TODO). I mean, will it work with bc? At the moment it's…
When I use your sed transformation on one of my directories, I see entries like: drwxr-xr-x 1,653 dalke admin 56,202 Mar 5 2,012 pubchem -rw-r--r-- 1 dalke staff 59,252 Nov 16 2,011 pubchem_10,000.fps.0.9.cluster I don't want to see the year written "2,012", and the file name is 'pubchem_10000" not "pubchem_10,000".
https://github.com/samsonjs/bin/blob/master/ls-comma
It's a disgusting hack and it works very well. I didn't find anything useful in the man page so I wrote this instead. Looks like there is something in the man page but I think my hack was probably faster.