ROOT seems to intercept some command line parameters as soon as the first binding happens.
Can this be avoided?
This is ROOTtest.py:
[code]from ROOT import TH1
if ‘–help’ in sys.argv[1:]: print >> sys.stderr, “Help!!!”
Some output now:
[code]$ python -V
$ root-config --version
$ python ROOTtest.py
$ python ROOTtest.py --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”.
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.