Re: [gentoo-dev] Bashrc mini HOWTO

[Jonas Geiregat]

Chris White wrote:

>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
>
>
I gave this a quick look, and aren't you talking about bash scripts in
general rather then .bashrc files using /etc/portage/bashrc as reference
for this document.
Also I can't see the real use , that's why I started reading then
quickly scanned through it .. and now I'm writting this email ..
-- 
gentoo-dev@g.o mailing list