Physics Hacker

If you run a python script that imports GaudiPython (or any LHCb modules for that matter) inside gdb on any lxplus node, you will run into an error like this:

[lxplus223] ~ > gdb python
GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"
   ...Using host libthread_db library "/lib64/tls/libthread_db.so.1".

(gdb) set args test.py
(gdb) run
Starting program:
   /afs/cern.ch/sw/lcg/external/Python/2.5.4p2/slc4_amd64_gcc34/bin/python test.py
[Thread debugging using libthread_db enabled]
[New Thread 182894205120 (LWP 11117)]
Traceback (most recent call last):
  File "test.py", line 1, in
    import GaudiPython
ImportError: No module named GaudiPython

Program exited with code 01.
(gdb)

This is due to our group-login script (including the “rc” one)
using LbLogin and that reshuffles the paths. When gdb starts
the process to be debugged and if a SHELL variable is present,
it is started with “$SHELL -c”.
When it is perfectly legal for bash (it only starts a new shell),
with (t)csh it starts a new *login* shell corrupting the already
setup paths (PATH, LD_LIBRARY_PATH, PYTHONPATH etc).

So in order to solve this you have to unset SHELL inside
gdb (maybe best to place that in .gdbinit):

unset environment SHELL

I’m not a great fan of shell scripts, and have a hard time performing anything even slightly complex with them. Unfortunately sourcing shell scripts is something that is often hard to avoid. So here is a trick to use python for all the logic required and only using the shell script as a wrapper.

The shell script basically just executes a given python script, passing along all the arguments. One argument is reserved for identifying the type of script (sh or csh) calling the python script. Python outputs shell commands that are then evaluated in the shell by ‘eval’.

For bash:

#!/bin/bash
eval `$MYSCRIPTS/test.py sh $@`

For csh:

#!/bin/csh
eval `$MYSCRIPTS/test.py csh $argv`

The python script can then perform the complex stuff and print shell commands for the relevant shell type.

#!/usr/bin/env python
import sys

# Distinguish between sh and csh
shelltype = sys.argv[1]

# Get the rest of the arguments
arguments = sys.argv[2:]

# Generate some fancy commands for the shell
shellcommands = createfancycommands(shelltype, arguments)

# This is shown to the user
print >> sys.stderr, ‘Use stderr for user info:’

# This is evaluated by the shell
print shellcommands

And, voilà, the python script takes care of all you worries. Also the overhead involved in supporting both sh and csh is drastically reduced.

Since we all love the tcsh (at least thats CERN’s point of view) ,

let me remind you that reverse search in tcsh is done by pressing

ALT-p

or for reverse order

ALT-P