On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <btc@openinworld.com> wrote:
phil@highoctane.be wrote:

��

On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:

�� �� EstebanLM wrote
�� �� ��> is cool.
�� �� ��> I would like to explore the possibility to replace our command
�� �� line parser
�� �� ��> with getopt. You know��� is more compatible at the end :)

�� �� I find the implementation of our command line handlers very
�� �� confusing. It
�� �� seems like it grew organically from a smaller idea and the design
�� �� got out of
�� �� control. There are many assumptions that can make it hard to extend,
�� �� especially to combine multiple options, as Ben and I discovered when
�� �� implementing the "don't run startup scripts" handler. It would be
�� �� nice to
�� �� revisit starting from a behavioral specification.


Well, what makes you say that?
The core CommandLineHandler itself is pretty generic and can do a lot of things.

Then, yeah, what is under is quite varied. But that's to be expected when trying out "new tech".

I've been making one of my own here for a given project with about 20-30 commands and I had to put in some structure indeed.

Is that part available somewhere that can be reviewed ?

You mean?

CommandLineHandler and CommandLineArguments is in the base image.

Phil
��
cheers -ben