Bug266 Editing
The current GetOpt is designed to be used in a cascading fashion, with each application 'consuming' some of the command-line arguments. For example, we did have a GetOpt in the Console, which required passing in argc/argv to extract the appropriate terms. [Please correct me if I'm wrong about this] The problem with this was that the console option was in a separate GetOpt object, and the GetOpt object used to list the command-line options was created before the former was created, so printing the usage message never showed the Console options. Instead we moved to passing in the Console options directly, IIRC, and having the console options added directly to the basic GetOpt. The issue with adding options to the GetOpt database could be managed by using a global database of options, and adding them using global (static) variables which on instantiation register options in that db. This does not resolve the issue of conflicts of options having the same name. We could have a namespace system for options, eg. for the console have 'console', with options such as 'console:list-available', 'console:select' and so on. The 'core' GetOpt module (non-nested namespace) could list just the core options, plus a list of sub-menus (so you can do --help for the core list, plus --help:console for the 'console' namespace. Would using colons be too messy? One alternative which I've been playing with is having a config-file which is parsed (first), with command-line options being able to override those elements (or append to them), so rather than having specific console options you have something like a line from the config-file: -a="ContactBias : Drain 2.0" -o="ElectricField : 3E5" This isn't exactly easy to understand however, and perhaps is something to use in *addition* to the basic (core) options. That is, for simple options in the core server we might use command-line options; options for specific kits, or console modules, might be read from the RCManager (or Moscow...) instead, with separate command-line options which change the config-file being used to affect those. For example, modules dynamically loaded into the server aren't exactly amenable to having their options printed on the command-line! Though this could be worked around...something like berlin-kits in the main server!
S1B78h <a href="http://vnkbkazzqxzd.com/">vnkbkazzqxzd</a>, [url=http://yoxokbermoia.com/]yoxokbermoia[/url], [link=http://rntybcsvtytv.com/]rntybcsvtytv[/link], http://tbnnfnngpdrw.com/
pi78Cf <a href="http://hxosgjsynmfr.com/">hxosgjsynmfr</a>, [url=http://uqkeqkwvryym.com/]uqkeqkwvryym[/url], [link=http://bvwmbrydieab.com/]bvwmbrydieab[/link], http://uauevmuccybl.com/
not logged in
register
Home