Live data from Hacker News

Hacking ls -l

lemis.com

61–70 of 93 posts

Re: Hacking ls -l

#61

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'.

I believe that's only supported in newer versions of sort.

Re: Hacking ls -l

#62
post #24
post #2

While 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.

It just depends what info you desire. I typically use "ls -lh" to quickly find large files to clean up to recover disk space.

Re: Hacking ls -l

#63

Earlier 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…

A reasonably recent sort from GNU coreutils has a -h (and equivalent long option --human-numeric-sort) which properly sorts the output of du -h, meaning you can do:

du -h | sort -h

And get properly size-sorted output.

Re: Hacking ls -l

#64
post #58
post #55

Incidentially, 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

I think it should be: http://joeyh.name/blog/entry/ls:_the_missing_options/

Re: Hacking ls -l

#65
post #49

Most 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.

Yes to both points. I haven't read the source code, but this feels like a case of code-oriented-programming instead of data-oriented-programming. In other words, they write printf twice: once in the C library, and once in the warning system. A more careful programmer might write both in terms of a ruleset that's declared a single time.

(Or they did that and it's just a bug somewhere.)

Re: Hacking ls -l

#66

Most 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.

Re: Hacking ls -l

#67
For such large numbers, would it make more sense to use groups of 6 instead of 3? This would allow you to easily identify the megabyte position with the next separator at the terabyte position.

Re: Hacking ls -l

#68
post #66

Most 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.

You're arguing that the GNU C Library is incompatible with the GNU Compiler Collection?

(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

#70
post #19
post #11

Earlier 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".

The easiest and naive way to fix that is to buffer the whole thing. Don't use this to do `ls-comma -lR ~`, but only on small directory hierarchies.

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.

Post reply on HN