i always use one hack for ls. alias lsd="ls -ltrF | grep ^d" This way, I quickly run lsd to only look for directories.
But lsd makes you see things that aren't even there.
Hacking ls -l
51–60 of 93 posts
Re: Hacking ls -l
#52I 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?
512 byte blocks for ls is specified by POSIX. That would probably be a painful change now.
Re: Hacking ls -l
#53-h
Re: Hacking ls -l
#54Earlier quoted context omitted.
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…
I think you're complaining too much about this momentarily being the top story on HN: (it feels to me as if) usually the top story is gossip about how much money some startup raised or an Apple vs Android piece. I find this to be an improvement.
Re: Hacking ls -l
#55Incidentially, 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.)
Re: Hacking ls -l
#56While 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.
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 )
Re: Hacking ls -l
#57gobble.wa@gmail.com made a similar post to the freebsd-questions mailing list a month ago. In his case the question was how to print an md5sum along with the file names in a given directory. I saved it because I thought it was a clever hack.
http://lists.freebsd.org/pipermail/freebsd-questions/2012-Se...
A lot of times I catch myself in the mindset of taking a step back and saying "here are the set of tools I have at hand to accomplish a task" without realizing that I should simultaneously be taking a step "in"--so to speak--and acknowledging that the tools I have to work with are not immutable tools cast of iron; they are malleable and can be re-tooled to suit my purposes.. and that sometimes going that route can be the simplest--and in fact "best"--solution.
Re: Hacking ls -l
#58Incidentially, 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
#59[deleted]
Re: Hacking ls -l
#60Guys! 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…
You assume that systems tend to be well-designed and the basic assumptions it makes are justifiable, and that the systems faithfully implement that design and those assumptions.
It sounds like the author found a bunch of bugs in the process of making a simple code change. That happens pretty frequently, and doesn't mean that the author should let the priests of the cathedral deal with this UNIX thing that is too complicated for the laity to hack on. It just means there is no priesthood.