[gentoo-dev] Bashrc mini HOWTO

[Chris White <chriswhite@gentoo.org>]

Hi guys,

	Well, I was working on my bashrc one day and thought, "gee, would be nice for other people to know what the heck is going on too!".  Well, I decided to go ahead and do that :P.  So, here we go, a mini bashrc HOWTO (note this only works on the latest stable of portage.  You go grab cvs head and try this, you can kiss yer but goodbye! :D).

HOW DOES IT WORK

if [ -f "${PORTAGE_BASHRC}" ]; then
        source "${PORTAGE_BASHRC}"

This little code in ebuild.sh pretty much sums it up.  Basically, when ebuild.sh is run with various ebuild stages (unpack, compile, postinst, etc.. etc.. etc.), it sources the bashrc file (located in /etc/portage/bashrc), giving it the exact same environment as ebuild.sh has.  So, your bashrc file pretty much ends up like a mini ebuild.  Now that we've explained that, let's get down and dirty.

LET'S USE IT

        case "$*"  in
                # stay really quiet here.
                depend) : ;;
                *)
                        [ "$*" = "compile" ] && package-pre-compile
                        [ "$*" = "postinst" ] && package-post-install
                ;;
        esac

Here's some sample code for my small bashrc file.  This is something I pulled from solar's bashrc and adjusted it a bit.  "$*" is all parameters passed to the program.  This means the ebuild stage in this particular case.  So package-pre-compile is run when the compile stage is hit, and package-post-install is run when the postinst stage is hit.  Here, depend is silenced, as ebuilds get depend'ed a LOT, things get kind of noisy.  Now that we know what stages we can run stuff at, let's see what we can do with environmental variables.

ENVIRONMENTAL VARIABLES

Well, first off portage is kind of restrictive.  That said, anything you need to pull from /usr/bin  you're probably going to have to add it to PATH:

        package-post-install() {
                        PATH=$PATH:/usr/sbin:/usr/bin:/bin:/sbin

As such.  If you have program not found errors, chances are you didn't do this.  So now, what about FEATURES.  That's right,  you can actually use FEATURES as well to cook up some nice stuff.  In my case, I had portage update the whatis database when it's done installing.  This is nice because I'm horribly lazy and wouldn't have the guts to do it manually/add a cron job.  Here we go:

                        if has whatis ${FEATURES} && test -x /usr/sbin/makewhatis ; then
                                echo "*** whatis enabled.  Updating the whatis database..."
                                # update the whatis database
                                `makewhatis -u`
                        fi
        }

Alright so, remember how I said that bashrc is a mini-ebuild?  Note how you can use the same "has" command that ebuilds can.  This is because we're being sourced from ebuild.sh, and therefore have all its functions.  What does that mean?  That means you get this:

addread
addwrite
adddeny
addpredict
esyslog
use
usev
useq
has
hasv
hasq
has_version
portageq
best_version
use_with
use_enable
diefunc
check_KV
keepdir
unpack
strip_duplicate_slashes
all the stuff described in man 5 ebuild (too lazy to list here)
killparent
remove_path_entry
do_newdepend
inherit (yes.. you can inherit eclasses.. weird ain't it...)
debug-print-function
debug-print-section

And you also notice FEATURES.  It can even do all the nifty portage variables too (default and in /etc/make.conf).  So that's it, with this nice little touch you can do cool customizations to the portage process, without messing with portage code ;).

Chris White
-- 
gentoo-dev@gentoo.org mailing list