On Tue, Nov 25, 2008 at 08:54:29PM -0800, Zac Medico wrote: > Ned Ludd wrote: > > On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote: > >> On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote: > >>> Given the following: > >>> # qlist -Iv sys-apps/portage > >>> sys-apps/portage-2.1.4.5 > >>> > >>> How do I safely extract the "2.1.4.5"? > >>> > >>> (I don't necessarily need to use qlist. Just want to get the version of > >>> an > >>> installed package within a bash script) > >> This *really* should be folded into portageq offhand- it's the initial > >> step towards shifting versionator logic (yet another standalone > >> parser/comparison implementation) into the PM. > >> > >> Counter arguements? > >> ~brian > > > > Yes. he said a bash script. portageq still takes a few seconds to load > > and invokes far far to many instructions for very simple info. > > > > The 3 execve's I just posted are still faster than one portageq call. > > So.. foo.c wins again. :p > > Well, I think portageq will be fine if it's limited to a small > number of calls. Here's a simple test, with portage-2.2_rc16: > > # time python -c "import portage.versions" > > real 0m0.141s > user 0m0.124s > sys 0m0.016s > > It's not so bad if it only has to be called a few times. For cases > where a large number need to be split, they could be processed in a > batch by a single portageq call, by either passing all the inputs in > as arguments or writing them to stdin.
So.. eapi3 meanwhile? ~brian
pgpKSvBtWJRoM.pgp
Description: PGP signature
