diff options
author | kotfu <kotfu@kotfu.net> | 2019-07-14 21:31:23 -0600 |
---|---|---|
committer | kotfu <kotfu@kotfu.net> | 2019-07-14 21:31:23 -0600 |
commit | 9325989ae5c7aa463b34bdc6997445a9603030d4 (patch) | |
tree | 84cbbbd8131aa3bc98a9b73b96532551c998e532 /docs/migrating | |
parent | aa34722a54e2ccfd2b831624e6219464e520d834 (diff) | |
download | cmd2-git-9325989ae5c7aa463b34bdc6997445a9603030d4.tar.gz |
Finish migration documentation for #719
Diffstat (limited to 'docs/migrating')
-rw-r--r-- | docs/migrating/incompatibilities.rst | 26 | ||||
-rw-r--r-- | docs/migrating/index.rst | 2 | ||||
-rw-r--r-- | docs/migrating/minimum.rst | 51 | ||||
-rw-r--r-- | docs/migrating/next_steps.rst | 60 | ||||
-rw-r--r-- | docs/migrating/why.rst | 36 |
5 files changed, 139 insertions, 36 deletions
diff --git a/docs/migrating/incompatibilities.rst b/docs/migrating/incompatibilities.rst index 014df7ff..db70798b 100644 --- a/docs/migrating/incompatibilities.rst +++ b/docs/migrating/incompatibilities.rst @@ -15,11 +15,9 @@ The `Cmd.emptyline() called when an empty line is entered in response to the prompt. By default, in cmd_ if this method is not overridden, it repeats and executes the last nonempty command entered. However, no end user we have encountered views this -as expected or desirable default behavior. Thus, the default behavior in -``cmd2`` is to simply go to the next line and issue the prompt again. At this -time, ``cmd2`` completely ignores empty lines and the base class -cmd.emptyline() method never gets called and thus the emptyline() behavior -cannot be overridden. +as expected or desirable default behavior. ``cmd2`` completely ignores empty +lines and the base class ``cmd.emptyline()`` method never gets called and thus +the empty line behavior cannot be overridden. Cmd.identchars @@ -29,15 +27,17 @@ In cmd_, the `Cmd.identchars <https://docs.python.org/3/library/cmd.html#cmd.Cmd.identchars>`_ attribute contains the string of characters accepted for command names. cmd_ uses those characters to split the first "word" of the input, without requiring the user -to type a space. For example, if ``identchars`` contained a string of all alphabetic -characters, the user could enter a command like ``L20`` and it would be interpreted -as the command ``L`` with the first argument of ``20``. +to type a space. For example, if ``identchars`` contained a string of all +alphabetic characters, the user could enter a command like ``L20`` and it would +be interpreted as the command ``L`` with the first argument of ``20``. Since version 0.9.0, ``cmd2`` has ignored ``identchars``; the parsing logic in ``cmd2`` splits the command and arguments on whitespace. While cmd_ technically -supports unicode, as a practical matter, it would be nearly impossible to -enumerate all the "alphabetic" unicode characters in the ``identchars`` -attribute. +supports unicode, but using non-ascii unicode characters in command names while +simultaneously using ``identchars`` functionality is non-trivial. Requiring +white space to delimit arguments also ensures reliable operation of many other +useful ``cmd2`` features, including :ref:`features/completion:Completion` and +:ref:`features/shortcuts_aliases_macros:Shortcuts, Aliases, and Macros`. If you really need this functionality in your app, you can add it back in by writing a :ref:`Postparsing Hook <features/hooks:Postparsing Hooks>`. @@ -57,7 +57,3 @@ scripts, Python scripts, transcripts, and history replays, the only way to preserve consistent behavior across these methods was to eliminate the command queue. Additionally, reasoning about application behavior is much easier without this queue present. - -If developers need this sort of thing, they can add it in their application. -However, if they are not extremely careful there would likely be unintended -consequences. diff --git a/docs/migrating/index.rst b/docs/migrating/index.rst index 58253a4d..73d6b1c7 100644 --- a/docs/migrating/index.rst +++ b/docs/migrating/index.rst @@ -11,4 +11,4 @@ Migrating From cmd next_steps -.. include:: summary.rst
\ No newline at end of file +.. include:: summary.rst diff --git a/docs/migrating/minimum.rst b/docs/migrating/minimum.rst index d604cf7a..c23bbbd7 100644 --- a/docs/migrating/minimum.rst +++ b/docs/migrating/minimum.rst @@ -1,4 +1,51 @@ -Minimum required changes +Minimum Required Changes ======================== -The minimum required changes to move to cmd2 +``cmd2.Cmd`` subclasses ``Cmd.cmd`` from the standard library, and overrides +most of the methods. Most apps based on the standard library can be migrated to +``cmd2`` in just a couple of minutes. + + +Import and Inheritance +---------------------- + +You need to change your import from this:: + + import cmd + +to this:: + + import cmd2 + +Then you need to change your class definition from:: + + class CmdLineApp(cmd.Cmd): + +to:: + + class CmdLineApp(cmd2.Cmd): + + +Exiting +------- + +Have a look at the commands you created to exit your application. You probably +have one called ``exit`` and maybe a similar one called ``quit``. You also +might have implemented a ``do_EOF()`` method so your program exits like many +operating system shells. If all these commands do is quit the application, +you may be able to remove them. See :ref:`features/misc:Exiting`. + + +Distribution +------------ + +If you are distributing your application, you'll also need to ensure +that ``cmd2`` is properly installed. You will need to add this to +your ``setup()`` method in ``setup.py``:: + + install_requires=[ + 'cmd2>=1,<2` + ] + +See :ref:`overview/integrating:Integrate cmd2 Into Your Project` for more +details. diff --git a/docs/migrating/next_steps.rst b/docs/migrating/next_steps.rst index 3f560501..f43c69c9 100644 --- a/docs/migrating/next_steps.rst +++ b/docs/migrating/next_steps.rst @@ -1,6 +1,62 @@ Next Steps ========== -What features (with links to details) are easy to implement next +Once your current application is using ``cmd2``, you can start to expand the +functionality by levering other ``cmd2`` features. The three ideas here will +get you started. Browse the rest of the :ref:`features/index:Features` to see +what else ``cmd2`` can help you do. -:doc:`Help <../features/help>` + +Argument Parsing +---------------- + +For all but the simplest of commands, it's probably easier to use `argparse +<https://docs.python.org/3/library/argparse.html>`_ to parse user input. +``cmd2`` provides a ``@with_argparser()`` decorator which associates an +``ArgumentParser`` object with one of your commands. Using this method will: + +1. Pass your command a `Namespace +<https://docs.python.org/3/library/argparse.html#argparse.Namespace>`_ +containing the arguments instead of a string of text. + +2. Properly handle quoted string input from your users. + +3. Create a help message for you based on the ``ArgumentParser``. + +4. Give you a big headstart adding :ref:`features/completion:Completion` to + your application. + +5. Make it much easier to implement subcommands (i.e. ``git`` has + a bunch of subcommands such as ``git pull``, ``git diff``, etc). + +There's a lot more about :ref:`features/argument_processing:Argument +Processing` if you want to dig in further. + + +Help +---- + +If you have lot of commands in your application, ``cmd2`` can categorize those +commands using a one line decorator ``@with_category()``. When a user types +``help`` the available commands will be organized by the category you +specified. + +If you were already using ``argparse`` or decided to switch to it, you can +easily :ref:`standardize all of your help messages +<features/argument_processing:Help Messages>` to be generated by your argument +parsers and displayed by ``cmd2``. No more help messages that don't match what +the code actually does. + + +Generating Output +----------------- + +If your program generates output by printing directly to ``sys.stdout``, you +should consider switching to :meth:`cmd2.cmd2.Cmd.poutput`, +:meth:`cmd2.cmd2.Cmd.perror`, and :meth:`cmd2.cmd2.Cmd.pfeedback`. These +methods work with several of the built in :ref:`features/settings:Settings` to +allow the user to view or suppress feedback (i.e. progress or status output). +They also properly handle ansi colored output according to user preference. +Speaking of colored output, you can use any color library you want, or use the +included :meth:`cmd2.ansi.style` function. These and other related topics are +covered in :ref:`features/generating_output:Generating Output`. diff --git a/docs/migrating/why.rst b/docs/migrating/why.rst index 5445b03f..a166d648 100644 --- a/docs/migrating/why.rst +++ b/docs/migrating/why.rst @@ -32,18 +32,6 @@ further modifications. Migrating to ``cmd2`` will also open many additional doors for making it possible for developers to provide a top-notch interactive command-line experience for their users. -``cmd2`` provides a full-featured framework for creating professional-quality -interactive command-line applications. A few of the highlights of ``cmd2`` -include: - -* Applications created are full-featured shells in their own right with ability - to call shell commands, redirect command output, pipe command output to shell - commands, etc. -* Superior tab-completion capabilities, especially when using included argparse - decorators -* Both Python and ASCII text application scripting is built-in -* Ability to run non-interactively for automation purposes - Free Features ------------- @@ -51,10 +39,18 @@ Free Features After switching from cmd_ to ``cmd2``, your application will have the following new features and capabilities, without you having to do anything: -- More robust :ref:`features/history:History`. Both cmd_ and ``cmd2`` have readline - history, but ``cmd2`` also has a robust ``history`` command which allows you - to edit prior commands in a text editor of your choosing, re-run multiple - commands at a time, and save prior commands as a script to be executed later. +- More robust :ref:`features/history:History`. Both cmd_ and ``cmd2`` have + readline history, but ``cmd2`` also has a robust ``history`` command which + allows you to edit prior commands in a text editor of your choosing, re-run + multiple commands at a time, and save prior commands as a script to be + executed later. + +- Users can redirect output to a file or pipe it to some other operating system + command. You did remember to use ``self.stdout`` instead of ``sys.stdout`` in + all of your print functions, right? If you did, then this will work out of + the box. If you didn't, you'll have to go back and fix them. Before you do, + you might consider the various ways ``cmd2`` has of + :ref:`features/generating_output:Generating Output`. - Users can load script files, which contain a series of commands to be executed. @@ -76,3 +72,11 @@ new features and capabilities, without you having to do anything: ``cmd2``-based app. The transcript can be played back into the app as a unit test. + +Next Steps +---------- + +In addition to the features you get with no additional work, ``cmd2`` offers a +broad range of additional capabilties which can be easily added to your +application. :ref:`migrating/next_steps:Next Steps` has some ideas of where +you can start, or you can dig in to all the :ref:`features/index:Features`. |