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

21–30 of 93 posts

Re: Hacking ls -l

#21

Post by dalke »

guylhem wrote: post #15
memset wrote: post #12

Earlier quoted context omitted.

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!

Editing ls/print.c sourcecode and recompiling is not hacking in my definition. I usually consider the portability of the solution. I have linux i386 and x64 machines, my arm n900, an osx latop, etc. Recompiling ls (or, heavens forbid, cross compiling!) for each machine may be a bright idea. Adding a line to your profile that will take advantage of the existing tools like sed is closer to hacking in my definition, bec…

It's definition under my definition of 'hacking.' Consider that the GNU tools already implement non-portable extensions; this would be yet another one, were it added. Also, portability is not an essential requirement for "hacking." I do small programming exercises sometimes in order to understand a facet of how things work. Consider this as an exercise in how to use locale-dependent specifiers.

As I pointed out elsewhere, your sed code doesn't work because it changes too many numbers - including filenames and dates - in the output. Also, if the exercise is to understand localization then your sed code isn't appropriate because it hard-codes "," when some locales use a "." as the thousands separator.

And for completeness, your alias can't then mix and match other flags, like "ls -lRt". It's a single command with strange side-effects if you use it incorrectly:

    % lll -art
    sed: illegal option -- r
    usage: sed script [-Ealn] [-i extension] [file ...]
           sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

Re: Hacking ls -l

#22

Post by osteele »

Mr. Lehey managed to improve the system in such a way that it will subsequent changes for him and others easier, independently of whether the specific change to `ls` is never adopted. It's “five whys” applied to “why is this hard” and “how can I make it easier”. It's more effort, with a greater chance that much of it will survive the current context and requirements.

Some people improve the area they travel through, others leave debris, and many are noops who make no difference to those who come after. If there's not enough entropy fighters like Mr. Lehey working a system, it turns to kipple.

Re: Hacking ls -l

#23

Post by guylhem »

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

It's a 10 seconds trick that did the job and did not require recompiling.

EDIT: seeing how it has been downvoted, IMHO hacking is all about time and effectiveness. if you believe fixing ls print formats is such a crucial problem that it requires more than seconds of your time, we have different values.

Feel free to support the argument by showing your skills and improving the example.

Re: Hacking ls -l

#24

Post by pepve »

cheald wrote: 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.

Re: Hacking ls -l

#25

Post by jrockway »

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.

Re: Hacking ls -l

#26

Post by guylhem »

dalke wrote: post #21
guylhem wrote: post #15

Earlier quoted context omitted.

Editing ls/print.c sourcecode and recompiling is not hacking in my definition. I usually consider the portability of the solution. I have linux i386 and x64 machines, my arm n900, an osx latop, etc. Recompiling ls (or, heavens forbid, cross compiling!) for each machine may be a bright idea. Adding a line to your profile that will take advantage of the existing tools like sed is closer to hacking in my definition, bec…

It's definition under my definition of 'hacking.' Consider that the GNU tools already implement non-portable extensions; this would be yet another one, were it added. Also, portability is not an essential requirement for "hacking." I do small programming exercises sometimes in order to understand a facet of how things work. Consider this as an exercise in how to use locale-dependent specifiers. As I pointed out elsew…

Hmmm - the sed code was written to give a working 1 line example with the answer- just an example, or else some people might consider that it could be high-end wizardy worthy of recompilation.

Instead of complaining about an obvious flaw in the example, maybe you could be more constructive and fix it.

Hints:

- if you want to pass other flags, make it a function and use $@

- if you want to respect the filenames and dates, either fix the regex or write it in perl.

Shouldn't take you long - back from 1999 in perl FAQ:

http://www.perlmonks.org/?node_id=653

But now it's qualifies as hacking. I guess that's due to inflation.

This is so not hacker news.

Ask a perl golfer to make you a one-liner you can copy-paste in your profile if you absolutely need some working code.

Re: Hacking ls -l

#27

Post by righyeah »

Imagine if all UNIX users had taken this approach - making modifications to suit their own tastes, and writing a public diary entry, instead of making their own changes _and_ then trying to get them into the source tree so every UNIX user has them by default, regardless of whether they need/want them? Oh well. Too late now. (There are still people trying to add their own personalized features into UNIX source distributions... watch out for them.)

There is something very appealing about having these utilities be simple enough that you can quickly hack them to add some feature that you might need. They are arguably much more useful as basic building blocks than as complex programs that purport to handle any task.

When they start to become complex, with many features (cat -v?), that simple quick and dirty hacking, adding a little ad hoc feature, becomes more involved. Who knows, by the time you finish, you may want it added to the base system for everyone, to justify the time you spent! (I'm guessing here. I honestly don't know why people try to push their added features into the base distributions of UNIX utilities that everyone must use.)

Re: Hacking ls -l

#28

Post by pilgrim689 »

guylhem wrote: post #11
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…

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…

Your solution is the better one, but that does not take anything away from memset's argument, though... This is not about the solution. This is about the problem of having all these yaks to shave just to add a comma to some program's output.

Re: Hacking ls -l

#29

Post by dsr_ »

Now let's consider software lifecycle in a large context: longevity of forks.

If he doesn't send the changes off to upstream, and make a case good enough for them to be approved, then all this dooms him to maintaining his fork on all the platforms where he wants it until he gets sick of it or convinces someone else to do it for him.

Re: Hacking ls -l

#30

Post by memset »

guylhem wrote: post #15
memset wrote: post #12

Earlier quoted context omitted.

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!

Editing ls/print.c sourcecode and recompiling is not hacking in my definition. I usually consider the portability of the solution. I have linux i386 and x64 machines, my arm n900, an osx latop, etc. Recompiling ls (or, heavens forbid, cross compiling!) for each machine may be a bright idea. Adding a line to your profile that will take advantage of the existing tools like sed is closer to hacking in my definition, bec…

Sure, this is fair. I tend to use "hacking" to mean "tinkering", and it could be said that I have a fairly loose usage of the word.

To me, this article gets to the crux of what I find particularly delightful about hacking (tinkering?): unraveling layers of complexity underneath. I feel like I have a little better understanding of what's happening when I punch in `ls`, and I think that particular delight and knowledge is the kind of thing that appeals to tinkerers (hackers? :p) like myself. So - in my view - entirely appropriate for this crowd!

But you have a fair point; there's nothing particularly out-of-the-ordinary of this code or process, and in that sense, isn't newsworthy to hackers.

(I did not downvote you incidentally; I think it's interesting to get a sense of peoples' different thresholds for what constitutes "hacker." I play the saxophone, and an instructor once told me that people always came up to him and said "I want to be a musician. How can I do that?" Well it turns out that the moment you play "hot cross buns" on your instrument, you are indeed a musician. Perhaps not a skilled one, but you have in fact made music. I think of hacking in a similar way, and freely admit that it is a loose use of the word!)

Post reply on HN