Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking ls -l

lemis.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Hacking ls -l

#41

Post by dalke »

ChuckMcM wrote: post #38
tisme wrote: post #32

Earlier quoted context omitted.

You are entirely missing the point of this whole thing. It is exactly about showing how hard it is to get a trivial change right in every detail. Your 10 second hack is what is wrong with 10 second hacks in general and even with most real solutions that are not carefully thought out. It's not only that the devil is in the details it is all details. And you need to get all of them right, not just the current subset of…

While I think that is the point, I don't know if was the author's originally intended point. You see 'hacking it' would imply just getting it to work, I expected to see something, well hackish, like replace the format specifier with %s and then wrap the number in a function call to something which read an environment variable to figure out how to print the number. That would be a hack, what Greg is doing is engineeri…

"Hacker" has many meanings. A quick read of the Wikipedia entry for the term shows you that. RFC 1392 defines a hacker as "A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular." The only way to tell which definition is in use is via context, and for this case the meaning is unambiguously aligned with the RFC 1392 definition.

(Note that this RFC comes from the days when 'hacker' was becoming a widespread term for someone who breaks into computer systems; the RFC attempts to distinguish between a 'hacker' and a 'cracker.')

Re: Hacking ls -l

#42

Post by taf2 »

dalke wrote: post #19
guylhem wrote: 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".

this should fix that. ls -l | sed -e :a -e 's/\s\(.*[0-9]\)\([0-9]\{3\}\) /\1,\2 /;ta'

correction: sorry it will only fix the modifications to the filename - the year is still broken.

Re: Hacking ls -l

#43

Post by StavrosK »

cheald wrote: post #17
memset wrote: post #9

Guys! The point of this article is not to prescribe the only method of displaying human-readable file sizes. Obviously one could use `ls -lh`; the author clearly demonstrates that he is willing and able to read man pages to find answers. Rather, this is a pretty interesting look into what it actually entails to make what ought to be a very simple and straightforward change. It turns out that these simple changes are…

On the other hand, you could consider it a cautionary tale about not reinventing wheels, because a problem that may seem trivial at first often turns out to be far more complex than expected. This is why you try to re-use work when possible, rather than endlessly reinventing things, because while sure, adding a comma to the printf string is easy enough, your assumptions (English locale, compiler not trying to be clev…

If your definition of "breaking" things is "they don't work on the first try", everything I've ever tried to do was broken.

Re: Hacking ls -l

#44

Post by michael_h »

Aardwolf wrote: post #31

Man, such fragile stuff. Why not code a function yourself that turns a number into a string representing it decimally with the commas every three digits. I normally like and use good library functions and standards, but if they're that fragile and depend on your environment then no thanks.

not everyone uses commas to separate their number groupings. his solution will work for any locale.

Re: Hacking ls -l

#45

Post by barrkel »

Aardwolf wrote: post #31

Man, such fragile stuff. Why not code a function yourself that turns a number into a string representing it decimally with the commas every three digits. I normally like and use good library functions and standards, but if they're that fragile and depend on your environment then no thanks.

Because that would not be correct in Germany or other locales which use . for digit group separation and , for the decimal separator.

Re: Hacking ls -l

#46

Post by salgernon »

guylhem wrote: post #4

Is this front page worth materiel? I mean, it's good you took the time to add a ', but doing the same with sed would have been faster. Alternatively, do you know about ls -lhrS? It will print size in human formats and reverse sort the files by size - ie the bigger will be at the end of the list

Anyone who has ever had to work on a large system will instantly recognize what he's done here, and admire his approach, and light a candle in support of ever getting this patched all the way through the various broken projects. Remember, he's got to get a patch approved for gcc to get this to work, and only once that is done, in production, and generally available will he be able to submit a patch for ls. This is the reality of disparate projects with many maintainers and schedules. This may seem to be a trivial example, but it is entirely indicative of the process.

Re: Hacking ls -l

#47

Post by runejuhl »

bajsejohannes wrote: post #8
ghostfish wrote: post #5

Earlier quoted context omitted.

My thoughts exactly. This is just complexity for complexity's sake. Useful as an exercise, but the -h flag already does this is an even more readable manner.

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

Re: Hacking ls -l

#48

Post by halostatue »

memset wrote: post #12
guylhem wrote: post #4

Is this front page worth materiel? I mean, it's good you took the time to add a ', but doing the same with sed would have been faster. Alternatively, do you know about ls -lhrS? It will print size in human formats and reverse sort the files by size - ie the bigger will be at the end of the list

Yes, it is front-page worthy, because the details give us insight into how one might make any sort of change to a codebase like this. "If you want to be a hacker, these are specific steps I took to hack something up ." In a domain that most of us are not very familiar with!

More to the point, it also shows that an "easy" change isn't so easy. In the course of solving this "easy" change, the author added six new items to his personal to-do list.

As edw519 has said, a one line code change takes six days to implement.

Re: Hacking ls -l

#49

Post by Evbn »

jrockway wrote: post #25

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.

Re: Hacking ls -l

#50

Post by Evbn »

zapman449 wrote: post #3

Or, you could use 'ls -h'... (that said, I do see the utility, since it gives a more obvious visual queue as to the order of size differences... but if you're doing anything with the sizes programatically, you have to remove the commas afterwards... Short version: if you're going to do this, make it a unique flag, or a new flag modifier to the -l flag... don't overload the -l flag without recourse...)

Ideally a parser should respect locale, and use a sane format (not commas) for multiple numbers in a list.

Even better if the _ separator used by programming languages were a supported locale LC=C_FOR_HUMANS :-)

Post reply on HN