On 10/08/2013 11:59 PM, John P. Rouillard wrote: > > Hi all: > > I was reading the Environment part of the SEC manpage where isbt > discusses the SECRC variable. It doesn't answer my question as to what > happens if there are command line arguments passed to SEC > (e.g. --pid=/var/log/sec_instance1 ) as well as a SECRC set in the > environment. The man page says: > > .... Each remaining line is added to the argv array of SEC as a > *single* element. Also, the lines are added to argv in the order > they appear in the resource file. > > So what happens to existing lines in the ARGV that are set on the > command line? Are the SECRC elements: > > 1) appended to the argv list that was set up from the command line > (making the SECRC items override the values set on the command > line)
The command line arguments from SECRC are appended to the regular command line. Apparently the word "add" is somewhat confusing, but it means adding to the end like stringwise add does. > > 2) prepended to the argv list that was set up from the command line > (making the command line arguments override the values set > by SECRC) > > 3) replacing the argv list set on the command line > >>From the code (which uses push rather than unshift) it looks like it's > option 1 which I don't think is as useful as option 2. > > I expect the command line arguments to take precedence over the SECRC > arguments. > > If you don't have duplicate arguments I don't think it matters which > comes first. The only time I can see it being a problem is for --conf > where it changes the processing order of the conf files. I don't think > changing the order of --input files really matters in a practical way. > > So should the command line args take priority over the SECRC arguments? One advantage of SECRC options taking priority is the ability to dynamically override command line options which are constants during run time. While it is generally not important for options with multiple values (like --input, for example), it matters for single-value options, since changing their values in SECRC with HUP/ABRT signal has immediate effect on the executing program. However, if the command line would take priority, changing options like --socket-timeout, --blocksize or --childterm would require restarting the program if these options have also been given in the command line. Having the ability to tune option values without restart was a feature that quite many users wanted to have, and appending SECRC options to the end of the option list allows to introduce run time option changes for all scenarios. kind regards, risto > > -- > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Simple-evcorr-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
