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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent