Linux startup

While researching Bug:1672 I realized that the two binaries (chandler and chandler_bin) were pretty much doing everything that a shell script could do and most of it was already being done by the RunChandler^? and RunPython^? scripts. After realizing that, I decided to see what could be merged into a single script.

The following are the tasks I found (by scanning the source to the two binaries) that need to be done before Chandler.py can be run:

• verify CHANDLERHOME is set
• verify CHANDLERBIN is set
• build LD_LIBRARY_PATH to point to our specific libraries
• set PYTHONHOME
• set PYTHONPATH
• call the chandler-specific python and pass in Chandler.py

Except for the building of LD_LIBRARY_PATH, the above are pretty much stock shell items.

After playing with the cats for a bit, I realized that even the building of the lib path is also scriptable:

• find all .so files in any chandler child directories
• remove any reference to the python*/ directories (this removes a ton of spurious hits for the python2.3 libs)
• massage and mangle to get full path names and build the variable

and this is the command sequence that does it:

LIB_DIRS=`find $CHANDLERHOME -name *.so -printf "%h\n" | sort -u | grep -v -e python`

after getting LIB_DIRS set to a list of directories, then you just need to run that thru a for loop to build LD_LIBRARY_PATH

attached to Bug:1672 is a working shell script that I tested using the latest debian build (after removing chandler, chandler_bin, RunPython^? and RunChandler^?)

-- MikeT - 10 Nov 2004

Heikki pointed out a use-case I missed - need to make sure th CHANDLERHOME is set to the scripts directory and not the PWD to ensure that the script can be run from anywhere on the path. I've updated the Bug:1672 attachement to reflect that fix.

-- MikeT - 11 Nov 2004