Re: [Bashburn-info] NEW bashburn config file determination

[Steven W. O. <st...@sy...>]

On Tuesday, Sep 30th 2008 at 12:26 -0000, quoth Markus Kollmar:

=>I was nerved to only get bashburn to work by running "Install.sh"
=>which then in turn modifies "BashBurn.sh" to the correct "BBROOTDIR".
=>
=>This may work but has some disadvantages:
=>
=>1. Programs modifying other programs code is not always nice and clear. 
=>And if someone does not know the
=>
=>typeset BBROOTDIR='@@BBROOTDIR@@'
=>
=>construct there could happen ugly things. Also it may become a 
=>maintenance nightmare.

Think of BashBurn.sh as not being the script that you run unless it has 
been installed. What we could do is to rename the file to BashBurn.sh.in 
and then the target, derived object, or whatever you want to call it, 
would be BashBurn.sh. BBROOTDIR should not be a config parameter. Having 
it as a config param implies that it's ok to modify it and it never is. 
Also, the value of BBROOTDIR is used for one thing only: to locate where 
auxiliary files are kept, for purposes of sourcing them in or locating 
language files, etc. 

Also, BashBurn is no longer required to be installed by root. In fact, you 
can have multiple installations, each with its own BBROOTDIR.

=>2. Distributions can not clearly build their own package installer since 
=>bashburn does not work unless bashburn "Install.sh" is executed.

Markus, sorry, but I don't understand what you're saying. We started with 
Install.sh and we're still using it. If we were to also support rpm and 
deb packaging then the Install.sh content would probably end up also being 
inside the preinst and postinst scripts that accompany the package. But 
future packaging is not relevant to whether the BB script is the same as 
what we write.

Also, we have hard coded the shebang at the top of the script to be 

#!/bin/bash

That's pretty normal these days, but I remember a time when it was common 
for bash to be in /usr/local/bin and when perl scripts got complicated 
because some people had perl in /usr/bin and others had it in 
/usr/local/bin. In that case the script would start with (something like) 

#! @@BASHPATH@@ 

and then proper installation would just work correctly for everyone.

=>3. The user expects traditionally under unixes following strategies to 
=>search for config-file:
=> -> search user's $HOME for config.
=> -> search system wide config (mostly in "/etc/").
=> -> fetch some (hard-coded) default config or ask user interactively for 
=>config source or values.

I agree. We need to add a -c configfile option and/or a BASHBURNRC 
environment variable. But the utility *is* pretty small and I don't see a 
real need for individual config params to have to be searched for in a 
list of places.

=>I have now changed "BashBurn.sh" in my local trunk and added following 
=>(note that for this to work in "bashburn.rc" "BBROOTDIR" has to be added 
=>and set again):



=>
=>
=>-------
=>
=>#!/bin/bash
=>
=>###############################################################################
=># Checks whether given file is readable and a actual config file of 
=>bashburn.
=># IN[1]: FILENAME.
=># OUT[SUCCESS]: <TRUE>
=># OUT[FAILURE]: <FALSE>
=>function is_valid_configfile {
=>    test -r $1  &&  grep -q "VERSION: 3.x" $1
=>}
=>
=>
=>## Determine the root directory (BBROOTDIR) of bashburn where all
=>## additional programm files for basburn are.
=>## CASE1: user config from $HOME:
=>if is_valid_configfile "$HOME/.bashburnrc"
=>    then
=>    typeset BBROOTDIR=$(grep "BBROOTDIR" $HOME/.bashburnrc | cut -d: -f2)
=>## CASE2: global config from /etc/
=>    elif is_valid_configfile "/etc/.bashburnrc"
=>    then
=>    typeset BBROOTDIR=$(grep "BBROOTDIR" /etc/.bashburnrc | cut -d: -f2)
=>## CASE3: Config from bashburn Install.sh:
=>    else
=>    # NOTE: BBROOTDIR will be later actualized by bashburn installation 
=>script
=>    # "Install.sh".
=>    typeset BBROOTDIR='@@BBROOTDIR@@'
=>fi
=>
=>
=>-----------
=>
=>Let me know what you think. I have not checked it in yet, since our 
=>svn-server seems not online in the moment.
=>Like you see I have left the "@@BBROOTDIR@@" as last option, but maybe 
=>we should delete it if there is no good reason against it.

I'd much rather see something else, which would be to look in a list of 
places for a config file. Look first in $HOME, then look in /etc. (BTW, 
the filename in /etc should not begin with a dot. Nothing else does.) 

That in conjunction with the -c option above is something I see as a 
better solution. But look at what we're talking about. The discussion 
about the value of BBROOTDIR is getting complicated by the possible 
locations of the rc file. :-)

What I don't want to be doing is to not have @@BBROOTDIR@@ just so we can 
run bb out of the workspace. If that is the real issue then that's a 
seperate discussion.

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net