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@gentoo.org mailing list
