Command line parameters intercepted by ROOT

Hello!

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

import sys

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

Some output now:

[code]$ python -V
Python 2.4.3
$ root-config --version
5.18/00
$ python ROOTtest.py
$ python ROOTtest.py --help
Usage: python [-l] [-b] [-n] [-q] [dir] [[file:]data.root] [file1.C … fileN.C]
Options:
-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

[/code]

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!

Hi,

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]

Cheers,
Wim

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.

Thanks,
Wim

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.

Cheers,
Wim