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

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

On Tuesday, Sep 30th 2008 at 13:26 -0000, quoth Steven W. Orr:

=>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):


There's one more thing I'd like to add to what I wrote above. I've 
mentioned some of the things I'd like to shoot for in uncoming revs of BB. 
One of the things I've touched on was the concept of the installation not 
necessarily looking like the src workspace. One example of this concept is 
that we have an installation tree that is overcomplicated. We have a need 
for the (current) installation directory to have a lang subddir but we do 
not have a need for almost all the rest of the subdirectories. Let's get 
rid of burning, config, convert, func, menus and misc. How we program, or 
in other words, the shape of the workspace, is not usually related to how 
a relase should look. When you see projects where the release structure is 
a match of how the sandbox looked then what you're probably seeing is 
another case of where the developer never thought that the release 
structure could be optimized.

I'm just blue-skying here, but let's try this on for size. It may not be 
right, but the example shows the concept. Let's pretend that we have 
abandoned Install.sh  and we're now in rpm and debian package management 
land.

/usr/bin/bashburn	# NOT a symlink. Created by
			# filter < BashBurn.sh > bashburn
/usr/share/man/man1/bashburn.man
/usr/lib/bashburn/lib/*.sh 	# All the sourced files
/usr/lib/bashburn/lib/lang/*	# Assuming we didn't yet get to po files.
/usr/share/doc/bashburn/{README, HOWTO, NOTES, CREDITS, etc}

Markus, is this feeling any better?

=>
=>
=>
=>=>
=>=>
=>=>-------
=>=>
=>=>#!/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
=>
=>-------------------------------------------------------------------------
=>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
=>Build the coolest Linux based applications with Moblin SDK & win great prizes
=>Grand prize is a trip for two to an Open Source event anywhere in the world
=>http://moblin-contest.org/redirect.php?banner_id=100&url=/
=>_______________________________________________
=>Bashburn-info mailing list
=>Bas...@li...
=>https://lists.sourceforge.net/lists/listinfo/bashburn-info
=>

-- 
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