Re: GNU GLOBAL - few patches

[Pawel Wilk]

Hi,

On Thu, Feb 26, 2004 at 02:07:25PM +0900, Shigio Yamaguchi wrote:
> Hi,
> I'm working about your patch.
> 
> > diff -Nur global-4.6.orig/globash.rc global-4.6/globash.rc
> > ...
> > +if [ -n "$GLOBASH_HOME" ]; then
> > +     GHOME=$GLOBASH_HOME/.globash
> > +else
> > +     GHOME=$HOME/.globash
> > +fi
> 
> It seems that above solution needs individual environment variable
> for each application.

It is just a next layer I've needed to integrate. There was no chance before
to force globash to use customized directory. In this case we can use HOME_ETC
name of the variable of course, but if the system doesn't support it, why to 
use such
a strange name?

I was just thinking that GLOBASH_HOME is a good name for such a variable 
for globash, to not "dominate" it by the home_etc support, but to extend it,
and make the integration with home_etc possible if someone will need it (like 
me:).

Now, if some user doesn't have libhome_etc (nor HOME_ETC variable set), he also 
can
customize globash home directory, using GLOBASH_HOME (_almost_ same way he
can customize gtags configuration file using GTAGSCONF).

If you will look into the RPM specfile, you will see /etc/profile.d/
generation scriptlets, which are producing for example /etc/profile.d/globash.sh
with the following content:

alias globash='[ -z "$GLOBASH_HOME" ] && export GLOBASH_HOME="$HOME_ETC" ; 
/bin/bash --rcfile /etc/gtags/globash.rc'

This -z test condition is still needed to allow user to enforce GLOBASH_HOME's 
value.
(i've added the -z condition into specfile before a moment)

In PLD, if you will use conditional build (bcond) --without-home_etc for this 
specfile
to produce RPMs this profile.d script will contain:

alias globash='/bin/bash --rcfile /etc/gtags/globash.rc'

So, summarizing, my point was to:

1.) allow customized home directory for globash
2.) then integrate it with HOME_ETC

> Are there any standard method to get user's home directory
> like function get_home_etc() in shell script?

home-etc compliant binary programs should use libhome_etc,
which always trustes HOME_ETC environment variable (if it is
not possible to obtain the variable the library looks into the file
called ~/.home_etc, which should happend occasionaly, since standard
tools are in touch with the user's environment).

so,

home-etc compliant scripts which we are sure that are in touch with
user's environment doesn't have to call some binary (and the library via it),
they can simply trust the HOME_ETC variable's value.

Of course, it would be nice if the globash.rc contained:

if [ -n "$GLOBASH_HOME" ]; then
     GHOME=$GLOBASH_HOME/.globash
elif [ -n "$HOME_ETC" ]; then
     GHOME=$HOME_ETC/.globash
else
     GHOME=$HOME/.globash
fi

If such a modification is possible it makes me free from installing
profile.d hooks for globash. Yes, I should made it to be working in
that way before. :>

> > AC_MSG_CHECKING(for home-etc support)
> > AC_ARG_WITH(home-etc,
> > [  --with-home-etc[=DIR]     include home-etc support ],
> > [
> >         if test "$withval" = 'no'; then
> >                 AC_MSG_RESULT(no)
> >         else
> >                 case $withval in
> >                 ''|yes) HOMEETC=/usr/local/pgsql;;
> >                 shared) HOMEETC=${prefix};;
> >                 *)      HOMEETC=$withval;;
> >                 esac
> 

my typo in patch :> sorry.
for empty or 'yes' it should be set to /usr/local

standard tree for the library is:

/usr/local
|
+-- include (home_etc.h)
|
+-- lib (libhome_etc.a libhome_etc.so)
|
...

regards,

-- 
pawel