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.
Hacking ls -l
31–40 of 93 posts
Re: Hacking ls -l
#32Earlier quoted context omitted.
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.
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 the problem that you happen to be working on.
Re: Hacking ls -l
#33I enable this for GNU ls like: alias ls="BLOCK_SIZE=\'1 ls --color=auto" The above is a bit hacky and not very UNIXy as it's lumping more logic into ls, rather than splitting out into functional units. Number formatting being a very common requirement, I've proposed a design for a new numfmt GNU coreutil http://lists.gnu.org/archive/html/coreutils/2012-02/msg00085... which would be used like: ls -l | numfmt --field=5…
I really don't understand why block size is 512 by default. It should really be 1 by default.
Except for someone with an ancient hard disk who thinks in blocks instead of (mega, giga, etc...)bytes, who ever needs or wants that?
Re: Hacking ls -l
#34While I appreciate the story, what's wrong with `ls -lh`?
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.
Re: Hacking ls -l
#35Earlier quoted context omitted.
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 da…
You did not give a `working 1 line example with the answer.' It doesn't do the right thing, and I pointed out two failure cases.
My constructive criticism is that your approach is wrong, should not be done, and cannot be easily fixed. One should never attempt to process the general output of ls. It's doable - I lived through the years of processing the "list"/"ls" output from random ftp servers - but it's nasty. Sure, you can add '$@' but then you have to worry about, say, "-i", which shows the inode number as a new leading column or "-n" which shows user/group ids instead of names. How does your alias/perl script figure out which column is the one which needs the commas?
You'll either end up with a very fragile system (producing the erroneous output as your 1-liner does) or you'll end up trying to understand most of the ls command-line arguments and/or heuristics to guess based on the output. The well-known "BUGS" section of the Unix man page says "To maintain backward compatibility, the relationships between the many options are quite complex." You're in for a long slog if you go this route.
Yes, if you want a one-off solution for a specific set of outputs then your approach would work. That would be also be boring and trivial. The linked-to article, on the other hand, was interesting.
Re: Hacking ls -l
#36Earlier 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…
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…
I can totally agree with calling that tinkering - and also that it is interesting, if only (due to my diverging opinion on the merits of the approach) as a warning tale about how far one should go to try and fix a problem.
But, just like you, I consider that not newsworthy to hackers, yet at the moment it is the #1 item on HN and it kinda makes me sad especially because of the threshold - the idea that some people do consider that hacking - here of all places - is chilling :-/
Worse - #2 item is "more people should write". I beg to differ- more people should code, so that fixing a printf and recompiling ls wouldn't be newsworthy.
I'm sorry if it was interpreted as being rude- it was not the point - I just wanted to present alternative approaches to the problem, because reconsidering the problem is sometimes the right thing to do, especially when it escalate quickly in complexity.
Re: Hacking ls -l
#37i always use one hack for ls. alias lsd="ls -ltrF | grep ^d"
This way, I quickly run lsd to only look for directories.
Re: Hacking ls -l
#38Earlier quoted context omitted.
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.
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 engineering a change to ls(1) which allows for pretty printing the numbers. So to my way of thinking the title is wrong, it sets the expectation of a hack and leads to an engineering exercise.
Re: Hacking ls -l
#39ls -alh
You guys have to much time.
Re: Hacking ls -l
#40Earlier 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…
I think that's reflective of how experience levels change your perspective on how to approach a problem.
Someone with command line experience that is mostly a user of system utilities would think passing the output of ls through a filter is the way to go whereas someone with C experience that already has insight in how Unix is architected would do something more along the lines of what the author is doing. That's pretty much how unix got built to begin with, and probably both parties would qualify their solution as a 'hack'.
It's all perspective.