Efficacy
March 6th, 2008You have people who want to do everything as efficient as possible in the confines of what anyone defines efficient (which is never the same thing). For me personally that’s getting the results quickly without having to really think about or work for a few extra minutes at how to go about getting it with a single command. I’m far more likely to pipe something and grab what I need with another tool. For most situations this is fine and quick enough, as you’re not dealing with millions of records that would cause a difference of minutes/hours in runtime.
I have a few friends who always try to compress something into a single command and use some of the more esoteric abilities applications have. Find being one of the most powerful is a great example.
While I might do something like the following:
#note /mnt/floppy is just lazy mount of a external 1TB harddrive
find . -name '*.mpeg' | awk '{FS="/"; print $2}' | xargs cp -r /mnt/floppy/
those friends will point out and show that it can be done with:
find . -name '*.mpeg' -exec sh -c 'echo "$(basename "{}")"' \;
The two actually give slightly different results but the idea is the same. Both are valid ways to get the same ultimate result. The former took me about 10 seconds to write, the latter would take me probably about 2 minutes to write because I rarely make use of find’s -exec ability and would end up with a bunch of find: missing argument to `-exec’.
What’s really the point that I’m making here. Well its that this serves as a tool for learning for me. I might not make use of -exec often but learning about a new tool from a friend or a different way to think about a problem helps me grow as with my ability to script. For me, by looking at how others would do the same thing I’ve done, I get a clear picture of what each part of the program does. I’ve been introduced once again to applications I’ve forgotten about due to lack of use again by these people. tr was just such an application and is quite handy as well.
I also enjoy doing the scripting of stuff to make my job easier. It might ultimately take me longer the first time, but I save the time if I have to do it again. Course many of my things end up being used a single time to never be used again. It’d be interesting to just start collecting all the one time things I do with some notes to see what I have done/what I’m doing and see the progress/change over time.
Using the above as a metaphor, Gentoo and any Distribution in comparison (on a distro level) is very much like this. You use it for something and someone else will do it another way. Its no different ultimately as you get the same result. A working system, but it works for you the way you want it to and you get exactly what you want from it.
So what is it that you want to get from Gentoo?
March 6th, 2008 at 1:17 pm
Even if I knew how to write the second way of doing it, I would prefer the first way of doing it. It seems to convey the intent of what you are doing more than the second.
Kind of related, when I work in eclasses, I usually prefer using the way that will be easiest to understand at a glance The best example of this I can think of is preferring long switches, as opposed to short ones:
gem install -l /path/to/something
versus
gem install –local /path/to/something
March 6th, 2008 at 2:37 pm
I really feel like you about learning to script. Everyone think different and make different use of their Gentoo/AnyDistro but the “cool thing” is: you can do as you wish.
Even if the second way (find -exec) seems to be faster than the first one, it should be way slower.
Well, in the first you’re using a pipe and two extern calls. because of the pipe, the awk part will run in a subshell (which is bad for performance).
But the second way create a subshell foreach files with the sh -c, and the $() part will run in another subshell !
Just to be sure, i tested (several times) these two command in my music directory (only ~500 files):
(; find . -name ‘*.ogg’ | awk ‘{FS=”/”; print $2}’; ) 0.01s user 0.01s system 45% cpu 0.053 total
find . -name ‘*.ogg’ -exec sh -c ‘echo “$(basename “{}”)”‘ \; 0.78s user 1.14s system 79% cpu 2.401 total
March 6th, 2008 at 3:26 pm
kaworu:
Interesting, I’d of not expected that. Thanks for trying it out and letting me know about the results.
March 6th, 2008 at 5:07 pm
What I really like is the ease of going beyond the
distro limits — or even doing something else
within.
Be it sugar-jhbuild running
in gentoo as right now,
be it a micro rescue utility on
an 8M usb partition,
let it be the current xorg-intel from git –
i can adapt my system or program versions
easily to fit the task, plus it’s easy to roll
back.
Having killed it accidentally by taking out a
substancial part of the file system, ruining
portage even — some binaries cross-compiled
and an emerge emptytree — all is well.
That’s not things I could say for the binary
distros i used before.
Plus it’s reasonably more comfortable than
— as long as I don’t break philosophy.
(B)LFS
In a nutshell, I like to not having a steep edge
at the end of the supposed/supported use cases.
More often than not, Gentoo is v friendly there.
Thanks for making this happen.
March 6th, 2008 at 6:24 pm
For batch processing, ‘find … -exec …’ is almost always one of the worst things you can do. That’s at least one fork/exec for every single result (and in this example two per result). An xargs solution minimizes the number of forks as much as possible (within a shell environment, anyway).
Manganeez
March 7th, 2008 at 4:56 am
Actually in my mind, the find -exec blah is like the “quick and dirty”, doesn’t need to think a lot about it so i’d just write it in a snap.
the other one needs a bit of thinking and writing however (for me at least)
then performance consideration is another matter