lb-zsh

zsh goodies for LHCb

target audience

A collection of zsh completion functions to make everyday life of zsh users in LHCb easier.

The focus is analysts who use 5% of the options 95% of the time. Experts who need all options of all tools may want to do a bit more.

what's shipped and what's not

The package should not contain general zsh features which are useful outside of LHCb as well. Instead it is planned to contain only features which are useful to LHCb users only.

A border line case is the completion for root.

demo

See my blog post for a screencast.

helpful pointers

When developing the completions, this howto was of great help.

stackoverflow/stackexchange posts which helped:

• http://stackoverflow.com/questions/4824590/propagate-all-arguments-in-a-bash-shell-script
• http://stackoverflow.com/questions/59838/check-if-a-directory-exists-in-a-shell-script
• http://stackoverflow.com/questions/2953646/how-to-declare-and-use-boolean-variables-in-shell-script
• http://stackoverflow.com/questions/8742783/returning-value-from-called-function-in-shell-script
• http://unix.stackexchange.com/questions/67898/using-the-not-equal-operator-for-string-comparison

feature list

git-lb-use

git lb-use completes

• its command line options (e.g. connection protocol)
• projects from a list of hard coded projects
• suggests url stubs (cern gitlab, with its ports)

git-lb-checkout

the git-lb-checkout command gets completed as: git lb-checkout [remote/branch-or-tag] [package-in-remote-project] The first block only querries accessible branches and tags from remotes/projects which were added with lb-use before. Packages get completed from the official list of existing packages, filtered according to the project in the previous argument (when starting with git lb-checkout Stripping/master, only packages associated to the Stripping project get added. It is not checked if they exist in the chosen branch or tag).

getpack

The same function which returns a (shortened) list of packages for git-lb-checkout just provides all packages.

lb-run

lb-run completes projects (from a hard coded list), and suggests version numbers (checking the list of existing versions, starting to suggest from the most recent one). Afterwards, any (currenty) executable command gets completed, and a few common commands get suggested. After that, the completion for the chosen command is called. TODO: add nightly support

lb-dev

just does the first part of lb-run, i.e. no completion after the version number. TODO: add nightly support

lblogin

LbLogin knows about the -c option and has a hard coded list of common CMTCONFIG variables. For afsLbLogin and cvmfsLbLogin that's about it. For LbLogin.sh, also the _gnu_generic function is called to parse the help message and show all documented options.

GUESS

If you're (deep) inside a CMT project path, the GUESS alias will be PROJECT VERSION, which you can use with SetupProject or Lbglimpse.

run

Similarly, the run function searches for the run executable in an lb-dev project. Not to go too wild, I placed barriers not to go beyond $HOME or /. run can handle if it doesn't find run (will return an error instead of wildly running commands). Furhtermore, the run function forwards the exit code of the run executable.

bsub

complete -q and queue names, -R for CentOS7 submission, hint that -J is the job name.

bkill

suggest lxbatch job ids

bjobs

modified default listing

bkillall

function to kill all lxbatch jobs (asks for confirmation)

gaudirun.py

complete .py and .opts files and suggest options from --help

ganga

complete .py files and suggest options from --help

SetupDaVinci (and others)

Similar to lb-run, version numbers (from SetupDaVinci --list-versions) are suggested.

dirac-dms-lfn-accessURL

The two (for me) interesting grid storage elements are completed, such that I don't have to call dirac-dms-lfn-replicas just to look up how the CERN EOS MC storage element is called.

general TODO

None of the commands checks against the current CMTCONFIG.