Use @with_argument_parser for all methods which require argument parsing

[kotfu]

Many methods in cmd2 utilize the now deprecated @options decorator, ex. do_pyscript() and do_history(). Other methods like do_save() use pyparsing, which works, but it too should probably be migrated to @with_argument_parser. do_set() does custom argument parsing not utilizing any library. Still other methods do no argument parsing, but probably should, like do_load(). All of these should be moved to argparse based argument processing.

Methods which implement single word commands, like do_quit() and do_shortcuts() could be left to ignore all passed arguments, which is what they do now.

[tleonhardt]

Oh wow, I didn't realize that do_save() was using pyparsing for its parsing logic.

Everything should be migrated to use the argparse-based decorator for parsing if it needs special parsing or perhaps just the decorator which causes a list of arguments to get passed if it doesn't need special parsing but needs more than a single argument. Some of the existing functions which use @options, such as do_pyscript() were using it with an empty option list just so they could get a list of argument strings intstead of a single string - i.e. to take advantage of the shlex parsing provided by the @options decorator.

The custom argument parsing in do_set() is pretty non-standard in terms of the way it tries hard to cast anything into the type expected for the given setting, so I wouldn't recommend attempting to port that to an argparse-based solution.

[kotfu]

no changes required

• do_eos() - can't pass arguments to this command
• do_eof() - can't pass arguments to this command
• do_quit() - ignores all arguments
• do_ipy() - ignores all argument
• do_shortcuts() - ignores all arguments
• do_cmdenvironment() - ignores all arguments
• do_shell() - don't want to parse arguments because all input needs to get passed to the shell
• do_py() - don't want to parse arguments because all input needs to get passed to the python interpreter
• do_set() - does it's own parsing of arguments
• do_run() - does it's own parsing of arguments

convert to use @with_argument_list

• do__relative_load() - accepts single argument
• do_load() - accepts single argument
• do_help() - accepts single argument
• do_pyscript() - accepts multiple arguments
• do_edit() - accepts multiple arguments

convert to argparse

• do_show()
• do_history()

superseded

• do_save() - uses pyparsing for "save [n] [file_path]. Will be removed when Consolidate functionality of editing, saving, and showing the history of commands entered #252 is completed.

notes

The use_argument_list attribute breaks do_shell() and do_py(), because there is no way to reconstruct the original user input from a parsed argument list. So use_argument_list has to go.

[tleonhardt]

I have some thoughts/comments regarding a few of the "to investigate" methods that aren't necessarily related to this issue, but they could potentially be, so I thought I would share them ...

I've been thinking of eliminating the do_cmdenvironment() method. I don't think that it is something which is generically useful to end users of cmd2 applications and as such it feels out of place. It is mildly useful for developers while developing.

I've also been considering eliminating the do_show() method and turning it into a non-command method since it is called by do_set() anyways when do_set() is invoked with no arguments. Having both set and show feel redundant.

I've also toyed with the idea of either eliminating or modifying the do_shortcuts() method in the long run. The main problem with this one is I've seen multiple end users get confused that they can't create new shortcuts with this command. So it might make sense to eliminate it and find a clever way of displaying shortcuts in the built-in help. Alternatively, it might make sense to find a way to modify it to allow users to add new shortcuts.

Do you have an opinion on any of this one way or the other?

[kotfu]

Never used do_cmdenvironment() so no opinion there. I agree do_show() feels redundant.

As for do_shortcuts(), my initial reaction is that I don't want a way for users to create/modify shortcuts at runtime. But I really like the idea of eliminating the shortcuts command and instead modify help so that it shows what the shortcut is a synonym for.

[kotfu]

Just looked at do_cmdenvironment(), and agree its not generally useful to end users. However, since it is potentially useful to developers, what if we modified the set command to accept a -a/--all option. If you do "set --all" then you get the standard settings, and then a blank line, and then a line that says "Read only settings", and then the output of cmdenvironment. Then it would still be available, but would be less confusing for end users because there would be no cmdenvironment command in help.

[tleonhardt]

I think your above suggestion related to do_cmdenvironment() is an excellent one. Eliminating the cmdenvironment command, but adding a flag to the set command which would then also display read-only settings (which is basically what cmdenvironment does) would give a simpler help menu for end users, but preserve access to the additional information developers may desire.