Command line parameters intercepted by ROOT


ROOT seems to intercept some command line parameters as soon as the first binding happens.
Can this be avoided?

This is

[code]from ROOT import TH1

import sys

if ‘–help’ in sys.argv[1:]: print >> sys.stderr, “Help!!!”

Some output now:

[code]$ python -V
Python 2.4.3
$ root-config --version
$ python
$ python --help
Usage: python [-l] [-b] [-n] [-q] [dir] [[file:]data.root] [file1.C … fileN.C]
-b : run in batch mode without graphics
-n : do not execute logon and logoff macros as specified in .rootrc
-q : exit after processing command line macro files
-l : do not show splash screen
dir : if dir is a valid directory cd to it before executing

-? : print usage
-h : print usage
–help : print usage
-config : print ./configure options


In words, ROOT intercepts “–help” option as soon as it’s imported and prints the help message of the interactive ROOT session.
I actually had normal behaviour when using gStyle instead of TH1, but I can’t reproduce it anymore.

Also note that the one-line-program “from ROOT import TH1” presents the same issue, as does “import ROOT ; ROOT.gStyle”.

Thank you!


command line parameters are particularly important for ROOT b/c of batch/non-batch (a bit of history there … ). However, what it gets is sys.argv, so you can modify/massage that set before doing a from ROOT import TXyz.

Note that you can do “import ROOT” first w/o side-effects, because the TPyROOTApplication (which takes sys.argv) isn’t created on import, but on first use. So, this should work:

[code]import sys, ROOT #,

1) get from sys.argv what you want for your app, and handle it

2) cleanse sys.argv to leave only what ROOT needs

3) use ROOT.TXyz which causes TPyROOTApplication to be created[/code]


Thank you for your punctual answer.

Maybe you could consider implementing a ‘–’ option, GNU style, so that all the options following that one are ignored by TApplication and friends and pass through. Although, if b/c meant backward compatibility, this could be risky.

That should work fine. I notice that python itself uses “-” rather than “–”. I put in a filter for both: arguments beyond “-” or “–” are no longer passed to TApplication.


It’s me thanking you!

Just remember to document the change (maybe in TPyROOTApplication inline doc? the disappearing parameters weren’t documented there either), although I can hardly figure how this could affect some existing program.

Good idea; doc has been updated.