NAME
develop_bash.pl - a development startup script.
COPYRIGHT
Copyright (C) 2001, 2002 Mark Veltzer; All rights reserved.
LICENSE
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, USA.
DETAILS
MANIFEST: develop_bash.pl
PROJECT: meta
VERSION: 0.00SYNOPSIS
develop_bash.plDESCRIPTION
STANDALONE SPECIAL FILE
"AEGIS - the best project manager this side of the sahara..." As usual - take heed... This is the standard text to be a Meta developer. Place this text in a fixed location (~/.develop_bash /etc/develop_bash etc...) and source it at startup. some explanation on this file: This file exists because when we want to work on the baseline we have to set a few environment variables for the command line to work (we do work on the command line...). setting environment variables is not done from perl or other language scripts but rather from a shell script (the same one your'e using - currently bash2) because: 0. its not a practice to change your parent process data (it seems to me that you cant realy do that without the concent of your parent process). 1. its difficut. 2. its non standard. 3. I hate it. 4. Its impossible. Therefore we wrote this script. This script should be "sourced" as this is the only way to change the env variables of the calling process. Routines here are characterised by the fact that they change the environment parameters of the calling shell. A rule of thumb about putting routines here should be: if the routine is supposed to deal with environment parameters it should be here if not - write a perl script instead. The routines here change the runtime affecting values of variables - not the compile time ones...
Important for developers:
It is important that all the interactive stuff be done AFTER the basic path settings since they may run a few executables and those will need to path settings in order to run...
OPTIONS
None.
BUGS
None.
AUTHOR
Name: Mark Veltzer
Email: mailto:veltzer@cpan.org
WWW: http://www.veltzer.org
CPAN id: VELTZERHISTORY
0.00 MV move tests to modulesSEE ALSO
Carp(3), File::Basename(3), POSIX(3), strict(3)
TODO
-use long opt for all the options (and maybe even store them in a file ?!?).
-get the $- variable from the shell as input (the shell has it) and use it to make checks whether this script runs interactivly or not...
-make the file name where Peters shortcuts are to be a parameter.
-make this script with an option just to write the changes to be made to the environment and not do them and so we could run this without the shell at the end and just execute the stuff its telling us to.
-make routine in here more accessible in that users could change their platform / architecture in the middle of a shell session.
-make options to put the development stuff ahead of everything and the reverse.
-make the develop_chec_path function work.
-make stuff here more generic (all the variables are handled pretty much the same...).