Pythonic command line arguments parser, that will make you smile

Overview

docopt creates beautiful command-line interfaces

https://travis-ci.org/docopt/docopt.svg?branch=master

Video introduction to docopt: PyCon UK 2012: Create *beautiful* command-line interfaces with Python

New in version 0.6.1:

  • Fix issue #85 which caused improper handling of [options] shortcut if it was present several times.

New in version 0.6.0:

  • New argument options_first, disallows interspersing options and arguments. If you supply options_first=True to docopt, it will interpret all arguments as positional arguments after first positional argument.
  • If option with argument could be repeated, its default value will be interpreted as space-separated list. E.g. with [default: ./here ./there] will be interpreted as ['./here', './there'].

Breaking changes:

  • Meaning of [options] shortcut slightly changed. Previously it meant "any known option". Now it means "any option not in usage-pattern". This avoids the situation when an option is allowed to be repeated unintentionally.
  • argv is None by default, not sys.argv[1:]. This allows docopt to always use the latest sys.argv, not sys.argv during import time.

Isn't it awesome how optparse and argparse generate help messages based on your code?!

Hell no! You know what's awesome? It's when the option parser is generated based on the beautiful help message that you write yourself! This way you don't need to write this stupid repeatable parser-code, and instead can write only the help message--the way you want it.

docopt helps you create most beautiful command-line interfaces easily:

"""Naval Fate.

Usage:
  naval_fate.py ship new <name>...
  naval_fate.py ship <name> move <x> <y> [--speed=<kn>]
  naval_fate.py ship shoot <x> <y>
  naval_fate.py mine (set|remove) <x> <y> [--moored | --drifting]
  naval_fate.py (-h | --help)
  naval_fate.py --version

Options:
  -h --help     Show this screen.
  --version     Show version.
  --speed=<kn>  Speed in knots [default: 10].
  --moored      Moored (anchored) mine.
  --drifting    Drifting mine.

"""
from docopt import docopt


if __name__ == '__main__':
    arguments = docopt(__doc__, version='Naval Fate 2.0')
    print(arguments)

Beat that! The option parser is generated based on the docstring above that is passed to docopt function. docopt parses the usage pattern ("Usage: ...") and option descriptions (lines starting with dash "-") and ensures that the program invocation matches the usage pattern; it parses options, arguments and commands based on that. The basic idea is that a good help message has all necessary information in it to make a parser.

Also, PEP 257 recommends putting help message in the module docstrings.

Installation

Use pip or easy_install:

pip install docopt==0.6.2

Alternatively, you can just drop docopt.py file into your project--it is self-contained.

docopt is tested with Python 2.7, 3.4, 3.5, and 3.6.

Testing

You can run unit tests using the command:

python setup.py test

API

from docopt import docopt
docopt(doc, argv=None, help=True, version=None, options_first=False)

docopt takes 1 required and 4 optional arguments:

  • doc could be a module docstring (__doc__) or some other string that contains a help message that will be parsed to create the option parser. The simple rules of how to write such a help message are given in next sections. Here is a quick example of such a string:
"""Usage: my_program.py [-hso FILE] [--quiet | --verbose] [INPUT ...]

-h --help    show this
-s --sorted  sorted output
-o FILE      specify output file [default: ./test.txt]
--quiet      print less text
--verbose    print more text

"""
  • argv is an optional argument vector; by default docopt uses the argument vector passed to your program (sys.argv[1:]). Alternatively you can supply a list of strings like ['--verbose', '-o', 'hai.txt'].

  • help, by default True, specifies whether the parser should automatically print the help message (supplied as doc) and terminate, in case -h or --help option is encountered (options should exist in usage pattern, more on that below). If you want to handle -h or --help options manually (as other options), set help=False.

  • version, by default None, is an optional argument that specifies the version of your program. If supplied, then, (assuming --version option is mentioned in usage pattern) when parser encounters the --version option, it will print the supplied version and terminate. version could be any printable object, but most likely a string, e.g. "2.1.0rc1".

    Note, when docopt is set to automatically handle -h, --help and --version options, you still need to mention them in usage pattern for this to work. Also, for your users to know about them.

  • options_first, by default False. If set to True will disallow mixing options and positional argument. I.e. after first positional argument, all arguments will be interpreted as positional even if the look like options. This can be used for strict compatibility with POSIX, or if you want to dispatch your arguments to other programs.

The return value is a simple dictionary with options, arguments and commands as keys, spelled exactly like in your help message. Long versions of options are given priority. For example, if you invoke the top example as:

naval_fate.py ship Guardian move 100 150 --speed=15

the return dictionary will be:

{'--drifting': False,    'mine': False,
 '--help': False,        'move': True,
 '--moored': False,      'new': False,
 '--speed': '15',        'remove': False,
 '--version': False,     'set': False,
 '<name>': ['Guardian'], 'ship': True,
 '<x>': '100',           'shoot': False,
 '<y>': '150'}

Help message format

Help message consists of 2 parts:

  • Usage pattern, e.g.:

    Usage: my_program.py [-hso FILE] [--quiet | --verbose] [INPUT ...]
    
  • Option descriptions, e.g.:

    -h --help    show this
    -s --sorted  sorted output
    -o FILE      specify output file [default: ./test.txt]
    --quiet      print less text
    --verbose    print more text
    

Their format is described below; other text is ignored.

Usage pattern format

Usage pattern is a substring of doc that starts with usage: (case insensitive) and ends with a visibly empty line. Minimum example:

"""Usage: my_program.py

"""

The first word after usage: is interpreted as your program's name. You can specify your program's name several times to signify several exclusive patterns:

"""Usage: my_program.py FILE
          my_program.py COUNT FILE

"""

Each pattern can consist of the following elements:

  • <arguments>, ARGUMENTS. Arguments are specified as either upper-case words, e.g. my_program.py CONTENT-PATH or words surrounded by angular brackets: my_program.py <content-path>.
  • --options. Options are words started with dash (-), e.g. --output, -o. You can "stack" several of one-letter options, e.g. -oiv which will be the same as -o -i -v. The options can have arguments, e.g. --input=FILE or -i FILE or even -iFILE. However it is important that you specify option descriptions if you want your option to have an argument, a default value, or specify synonymous short/long versions of the option (see next section on option descriptions).
  • commands are words that do not follow the described above conventions of --options or <arguments> or ARGUMENTS, plus two special commands: dash "-" and double dash "--" (see below).

Use the following constructs to specify patterns:

  • [ ] (brackets) optional elements. e.g.: my_program.py [-hvqo FILE]
  • ( ) (parens) required elements. All elements that are not put in [ ] are also required, e.g.: my_program.py --path=<path> <file>... is the same as my_program.py (--path=<path> <file>...). (Note, "required options" might be not a good idea for your users).
  • | (pipe) mutually exclusive elements. Group them using ( ) if one of the mutually exclusive elements is required: my_program.py (--clockwise | --counter-clockwise) TIME. Group them using [ ] if none of the mutually-exclusive elements are required: my_program.py [--left | --right].
  • ... (ellipsis) one or more elements. To specify that arbitrary number of repeating elements could be accepted, use ellipsis (...), e.g. my_program.py FILE ... means one or more FILE-s are accepted. If you want to accept zero or more elements, use brackets, e.g.: my_program.py [FILE ...]. Ellipsis works as a unary operator on the expression to the left.
  • [options] (case sensitive) shortcut for any options. You can use it if you want to specify that the usage pattern could be provided with any options defined below in the option-descriptions and do not want to enumerate them all in usage-pattern.
  • "[--]". Double dash "--" is used by convention to separate positional arguments that can be mistaken for options. In order to support this convention add "[--]" to your usage patterns.
  • "[-]". Single dash "-" is used by convention to signify that stdin is used instead of a file. To support this add "[-]" to your usage patterns. "-" acts as a normal command.

If your pattern allows to match argument-less option (a flag) several times:

Usage: my_program.py [-v | -vv | -vvv]

then number of occurrences of the option will be counted. I.e. args['-v'] will be 2 if program was invoked as my_program -vv. Same works for commands.

If your usage patterns allows to match same-named option with argument or positional argument several times, the matched arguments will be collected into a list:

Usage: my_program.py <file> <file> --path=<path>...

I.e. invoked with my_program.py file1 file2 --path=./here --path=./there the returned dict will contain args['<file>'] == ['file1', 'file2'] and args['--path'] == ['./here', './there'].

Option descriptions format

Option descriptions consist of a list of options that you put below your usage patterns.

It is necessary to list option descriptions in order to specify:

  • synonymous short and long options,
  • if an option has an argument,
  • if option's argument has a default value.

The rules are as follows:

  • Every line in doc that starts with - or -- (not counting spaces) is treated as an option description, e.g.:

    Options:
      --verbose   # GOOD
      -o FILE     # GOOD
    Other: --bad  # BAD, line does not start with dash "-"
    
  • To specify that option has an argument, put a word describing that argument after space (or equals "=" sign) as shown below. Follow either <angular-brackets> or UPPER-CASE convention for options' arguments. You can use comma if you want to separate options. In the example below, both lines are valid, however you are recommended to stick to a single style.:

    -o FILE --output=FILE       # without comma, with "=" sign
    -i <file>, --input <file>   # with comma, without "=" sign
    
  • Use two spaces to separate options with their informal description:

    --verbose More text.   # BAD, will be treated as if verbose option had
                           # an argument "More", so use 2 spaces instead
    -q        Quit.        # GOOD
    -o FILE   Output file. # GOOD
    --stdout  Use stdout.  # GOOD, 2 spaces
    
  • If you want to set a default value for an option with an argument, put it into the option-description, in form [default: <my-default-value>]:

    --coefficient=K  The K coefficient [default: 2.95]
    --output=FILE    Output file [default: test.txt]
    --directory=DIR  Some directory [default: ./]
    
  • If the option is not repeatable, the value inside [default: ...] will be interpreted as string. If it is repeatable, it will be splited into a list on whitespace:

    Usage: my_program.py [--repeatable=<arg> --repeatable=<arg>]
                         [--another-repeatable=<arg>]...
                         [--not-repeatable=<arg>]
    
    # will be ['./here', './there']
    --repeatable=<arg>          [default: ./here ./there]
    
    # will be ['./here']
    --another-repeatable=<arg>  [default: ./here]
    
    # will be './here ./there', because it is not repeatable
    --not-repeatable=<arg>      [default: ./here ./there]
    

Examples

We have an extensive list of examples which cover every aspect of functionality of docopt. Try them out, read the source if in doubt.

Subparsers, multi-level help and huge applications (like git)

If you want to split your usage-pattern into several, implement multi-level help (with separate help-screen for each subcommand), want to interface with existing scripts that don't use docopt, or you're building the next "git", you will need the new options_first parameter (described in API section above). To get you started quickly we implemented a subset of git command-line interface as an example: examples/git

Data validation

docopt does one thing and does it well: it implements your command-line interface. However it does not validate the input data. On the other hand there are libraries like python schema which make validating data a breeze. Take a look at validation_example.py which uses schema to validate data and report an error to the user.

Using docopt with config-files

Often configuration files are used to provide default values which could be overriden by command-line arguments. Since docopt returns a simple dictionary it is very easy to integrate with config-files written in JSON, YAML or INI formats. config_file_example.py provides and example of how to use docopt with JSON or INI config-file.

Development

We would love to hear what you think about docopt on our issues page

Make pull requests, report bugs, suggest ideas and discuss docopt. You can also drop a line directly to <[email protected]>.

Porting docopt to other languages

We think docopt is so good, we want to share it beyond the Python community! All official docopt ports to other languages can be found under the docopt organization page on GitHub.

If your favourite language isn't among then, you can always create a port for it! You are encouraged to use the Python version as a reference implementation. A Language-agnostic test suite is bundled with Python implementation.

Porting discussion is on issues page.

Changelog

docopt follows semantic versioning. The first release with stable API will be 1.0.0 (soon). Until then, you are encouraged to specify explicitly the version in your dependency tools, e.g.:

pip install docopt==0.6.2
  • 0.6.2 Bugfix release.
  • 0.6.1 Bugfix release.
  • 0.6.0 options_first parameter. Breaking changes: Corrected [options] meaning. argv defaults to None.
  • 0.5.0 Repeated options/commands are counted or accumulated into a list.
  • 0.4.2 Bugfix release.
  • 0.4.0 Option descriptions become optional, support for "--" and "-" commands.
  • 0.3.0 Support for (sub)commands like git remote add. Introduce [options] shortcut for any options. Breaking changes: docopt returns dictionary.
  • 0.2.0 Usage pattern matching. Positional arguments parsing based on usage patterns. Breaking changes: docopt returns namespace (for arguments), not list. Usage pattern is formalized.
  • 0.1.0 Initial release. Options-parsing only (based on options description).
Comments
  • Support for counted short flags, a-la ssh -vvv?

    Support for counted short flags, a-la ssh -vvv?

    There's another idiom I've seen around the place where a short can be multiplied to increase its weight. The only one that springs to mind right this second is ssh:

     -t      Force pseudo-tty allocation.  Blah blah blah. Multiple -t options force 
             tty allocation, etc.
    
     -v      Verbose mode. Yada yada yada. Multiple -v options increase the
             verbosity.  The maximum is 3.
    

    Would this be something docopt could support, or do you think simply recommending people do -v 3 is enough?

    todo 
    opened by shabbyrobe 22
  • Make it possible to write 'xargs'

    Make it possible to write 'xargs'

    I have this test of options parsers, and almost every one fails, including docopt: Can I write 'xargs'?

    Here's a simplified usage string:

    """Usage:
      xargs.py [options] [COMMAND [ARG...]]
    
    Options:
      --null,-0               Input items terminated by 0
    """
    

    The problem is that Docopt allows interspersed options, per the GNU(?) convention. (This is a good default! I don't dispute that.) This means that the command line xargs.py foo -0 produces this option dictionary:

    {'--null': True,
     'ARG': [],
     'COMMAND': 'foo'}
    

    instead of this one:

    {'--null': False,
     'ARG': ['-0'],
     'COMMAND': 'foo'}
    

    Obviously I could require that the user enter -- in there, but that is both obnoxious and not the typical situation for a program which runs another command passed on the command line. (E.g. time, valgrind, env, etc.)

    (Incidentally, -- handling IMO doesn't seem very good either: If I run xargs.py -- foo what I get is

    {'--null': False,
     'ARG': ['foo'],
     'COMMAND': '--'}
    

    while standard convention is that the -- is basically transparent to the program's meaning and thus it seems like it should be transparent to the program's code, so forcing the programmer to manually shift the positional arguments down (or explicitly list a variant of the command with --) seems wrong.)

    0.6.0 
    opened by EvanED 21
  • Add support for [no-]options

    Add support for [no-]options

    It's common pattern to use boolean options like --[no-]paginate. They are missing in docopt. Does it have any reasons not to include such functionality or it's just not yet implemented?

    opened by VorontsovIE 20
  • YAML test cases

    YAML test cases

    I ported the agnostic tests (of 0.5.x) in YAML format while I was working on docopt_racc, as it was easier to edit and way more pleasant to read. It's available on docopt_racc repo and this was the script which aided the whole act, plus a ruby one liner to display output as YAML. They are prefixed with agnostic_..

    It'd be awesome if test cases were maintained in YAML files, so changes in docopt language reflect clearer in history and contributors be happier tracking down the failing cases..

    opened by johari 15
  • docopt.__doc__ docstring

    docopt.__doc__ docstring

    Does anyone think it's a good I dea to read docopt.__doc__ from README.rst file? I can't see people doing similar things, there should be a reason.

    I'm thinking of adding the following to docopt.py:

    try:
        import os
        docopt.__doc__ = open(os.path.join(
            os.path.dirname(os.path.abspath(__file__)), 'README.rst' )).read()
    except:
        pass
    
    opened by keleshev 15
  • Potential bug with default values?

    Potential bug with default values?

    I set myself a challenge to convert the large command line user interface of youtube-dl to use docopt. In doing so I encountered a problem which I have not been able to solve.

    My problem can be reproduced (I am using docopt v.0.6.1) with the file in https://gist.github.com/SavinaRoja/6859576 . Some of the options which receive arguments with default values fail to receive the defaults while others do. For example, '--playlist-start' receives a value of None while '--buffer-size' receives a value of '1024' as expected. Is this a bug in docopt's parsing or am I making a mistake?

    opened by SavinaRoja 14
  • Default not working?

    Default not working?

    Usage:
        cleanup.py
        cleanup.py [--dry-run] [--torrentfiles=<path>]
        cleanup.py [--dry-run] [--srts=<path>]
        cleanup.py [--dry-run] [--emptyfolders=<path>]
    
    Options:
        -h --help                Show this screen.
        --dry-run                Show files which would be deleted instead of deleting them.
        --torrentfiles=<path>    Remove files in path. If path in not a directory, look for associated subtitles too.
        --srts=<path>            Find and remove orphan subtitles in path.
        --emptyfolders=<path>    Find and remove empty folders or folders with no interesting files. [default: /example/path]
    

    --emptyfolders default no None. What am I missing here?

    opened by franciscolourenco 14
  • Seems like this is supported, but I can't get multiple arguments to work

    Seems like this is supported, but I can't get multiple arguments to work

    This is the docstring for punt.

    I would like to have multiple --watch options, but I can't figure out a syntax that supports it.

    """Watches current path (or another path) for changes and executes
    command(s) when a change is detected.  Uses watchdog to track file changes.
    
    Usage:
        punt [-w <path> ...] [-l] [--] <commands>...
        punt (-h | --help)
        punt --version
    
    Options:
        -w <path> ..., --watch <path> ...  Which path to watch [default: current directory]
        -l, --local                        Only tracks local files (disables recusive)
    """
    # blablabla
    arguments = docopt(__doc__, version='punt v1.6')
    print repr(arguments)
    
    > punt -w dir1 dir2  -- make
    {'--': False,
     '--help': False,
     '--local': False,
     '--version': False,
     '--watch': 'dir1',
     '-h': False,
     '<commands>': ['dir2', '--', 'make']}
    
    > punt -w dir1 -w dir2  -- make
    {'--': True,
     '--help': False,
     '--local': False,
     '--version': False,
     '--watch': 'dir2',
     '-h': False,
     '<commands>': ['make']}
    
    todo 
    opened by colinta 14
  • PHP port, all tests pass

    PHP port, all tests pass

    You know when you see something that you don't know how you ever lived without... We do mostly PHP where I work so rather than keep living without docopt I whipped up a quick and dirty transliteration.

    It passes all of the tests in the language_agnostic_parser, but it hasn't really been given much of a workout yet and there could be some issues I haven't found.

    https://github.com/shabbyrobe/docopt.php

    The main issue at the moment is that DocoptExit doesn't quite work in PHP like it should - SystemExit has no obvious analog in PHP so it currently requires a catch block, but I'm working on that.

    Thanks again for such a fantastic library, and a very, very big thanks for the language agnostic tester.

    opened by shabbyrobe 13
  • Another request for type annotations and conversions

    Another request for type annotations and conversions

    I just learned about docopt from your video featured in Python Weekly, and I must say it looks amazing! However, I was surprised to find that there is no functionality provided for annotating or converting the types of arguments. Even though this has been raised and closed twice before --

    https://github.com/docopt/docopt/issues/8 https://github.com/docopt/docopt/issues/58

    -- I think it is an important feature and I want to revisit it to add my perspective and support.

    The main arguments against adding this functionality seem to be:

    1. Simplicity is valuable.
    2. You can easily perform conversions elsewhere using Schema

    I will address each of these in turn:

    1. Yes, simplicity is valuable and one of the most compelling aspects of docopt. To preserve simplicity, let's consider allowing only the following type annotations: int, float, and string. Everything is a string unless otherwise annotated. This drastically reduces both implementation complexity and usage complexity as compared to a more featureful approach that would allow conversions to arbitrary, possibly user-defined Python objects.

      I think int and float would cover a large fraction of use cases. The only other types I would even consider supporting would be boolean and maybe file. Since docopt is presenting a generic command line interface, it makes sense to me that it would only support data types that are somehow "native" to the Unix ecosystem rather than arbitrary Python-specific types that have no Unix analogue. Ranges or sets of the supported primitives would also be candidates for inclusion -- I think they would be worth adding, but I agree they add complexity (both implementation-wise and in the DSL). So, start with just the really simple stuff!

    2. If an argument is required to be a particular type, I would like the command line help text to reflect that. If I've already specified the type in the usage message, why should I need to manually create a schema re-specifying portions of the interface?

      Schema looks like a very nice tool! What if docopt used the information it parsed from the usage string to automatically create the Schema and perform validations/conversions for me (behind the scenes)? That would be big win for clarity and usability and incur only minor implementation complexity.

    Anyway, I just wanted to add my two cents. Again, great job with docopt!

    opened by drewfrank 12
  • --help and --help-commands

    --help and --help-commands

    I see that this works better in the current master. Still, there is an issue:

     $ script.py --help
    

    will always trigger the --help-commands action, when I would expect it to show the help.

    bug 
    opened by miracle2k 12
  • Resolve invalid escape sequence warnings

    Resolve invalid escape sequence warnings

    Simple change to prefix any regular expression matching strings with r to ensure they are used as raw strings and do not throw an invalid escape sequence warning: image

    opened by daugihao 1
  • Short options in docopt not returning correct values

    Short options in docopt not returning correct values

    I am trying to use short options in docopt like this:

    Usage:
        someCMD [-a] [-b] [-c <cVar>] [-d <dVar>] 
    
    Options:
        -h, --help  Show this screen
        -a      Show a stuff
        -b      Show b stuff
        -c <cVar>   c stuff with var [default: thing1]
        -d <dVar>   d stuff with var [default: thing2]
    

    But that is not giving the anticipated result. For example someCMD -c anything puts the value under the dVar key in the resulting json. someCMD -c anything -d anythingelse doesnt work at all. someCMD -d anythingelse does put the value under dVar but cVar is set to someCMD instead of its default value.

    Here is a link to try it yourself using the docopt online tool.

    What am I missing?

    opened by khoopes 1
  • get_docopts.sh fails on M1 Monterey 12.6

    get_docopts.sh fails on M1 Monterey 12.6

    I attempted to install docopts on an Mac M1 laptop running Monterey 12.6

    git clone https://github.com/docopt/docopts.git ~/projects/docopts
    cd ~/projects/docopts
    ./get_docopts.sh
    

    I received the following error:

    I'm on macos I'm arm Fetching from: https://github.com/docopt/docopts/releases/download/v0.6.4-with-no-mangle-double-dash/docopts_darwin_arm --2022-10-11 11:33:28-- https://github.com/docopt/docopts/releases/download/v0.6.4-with-no-mangle-double-dash/docopts_darwin_arm Resolving github.com (github.com)... 140.82.113.3 Connecting to github.com (github.com)|140.82.113.3|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2022-10-11 11:33:28 ERROR 404: Not Found.

    download failure

    ERROR Tue Oct 11 11:33:28 EDT 2022 OSTYPE not supported yet, or missing arch: arm64 or download failure.

    You cat create an issue here: https://github.com/docopt/docopts/issues/

    URL=https://github.com/docopt/docopts/releases/download/v0.6.4-with-no-mangle-double-dash/docopts_darwin_arm OSTYPE=darwin21 ARCH=arm64 ARCH_BIN=arm getconf LONG_BIT 64 RELEASE=v0.6.4-with-no-mangle-double-dash

    opened by benscarlson 0
  • Please upload a wheel package to pypi

    Please upload a wheel package to pypi

    Builds using PEP517 and pyproject.toml no longer play nicely with pypi packages that require legacy build tools instead of simply installing a .whl file.

    Please upload one.

    opened by smurfix 5
  • Invoking help on a command prints options that don't apply to it

    Invoking help on a command prints options that don't apply to it

    Suppose you have a docstring as follows. Its intent is that the -s|--short option applies only to the info command, while the others apply to all commands:

    Usage:
        prog --help
        prog info [-s|--short] [options]
        prog do_thing [options]
    
    Commands:
        info       Print information
        do_thing   Do something
    
    Options:
    
        -s, --short      Shorter output
    
        -v, --verbose    Verbose output
        -D, --debug      Debug output
        -h, --help       Print help
    

    This does the Right Thing with respect to the options accepted; prog do_thing --short rejects the option and prints usage information. But the output of prog do_thing --help still includes --short. That seems wrong to me; when I do prog subcommand --help, I expect to see only those options that work with subcommand.

    Is this a bug, or intended behavior, or is there something I'm missing?

    [edit: this is using docopt v0.6.2]

    opened by andrew-vant 1
Corgy allows you to create a command line interface in Python, without worrying about boilerplate code

corgy Elegant command line parsing for Python. Corgy allows you to create a command line interface in Python, without worrying about boilerplate code.

Jayanth Koushik 7 Nov 17, 2022
Python Fire is a library for automatically generating command line interfaces (CLIs) from absolutely any Python object.

Python Fire Python Fire is a library for automatically generating command line interfaces (CLIs) from absolutely any Python object. Python Fire is a s

Google 23.6k Dec 31, 2022
Command line animations based on the state of the system

shell-emotions Command line animations based on the state of the system for Linux or Windows 10 The ascii animations were created using a modified ver

Simon Malave 63 Nov 12, 2022
Python composable command line interface toolkit

$ click_ Click is a Python package for creating beautiful command line interfaces in a composable way with as little code as necessary. It's the "Comm

The Pallets Projects 13.3k Dec 31, 2022
Library for building powerful interactive command line applications in Python

Python Prompt Toolkit prompt_toolkit is a library for building powerful interactive command line applications in Python. Read the documentation on rea

prompt-toolkit 8.1k Dec 30, 2022
Color text streams with a polished command line interface

colout(1) -- Color Up Arbitrary Command Output Synopsis colout [-h] [-r RESOURCE] colout [-g] [-c] [-l min,max] [-a] [-t] [-T DIR] [-P DIR] [-d COLORM

nojhan 1.1k Dec 21, 2022
Python Command-line Application Tools

Clint: Python Command-line Interface Tools Clint is a module filled with a set of awesome tools for developing commandline applications. C ommand L in

Kenneth Reitz Archive 82 Dec 28, 2022
prompt_toolkit is a library for building powerful interactive command line applications in Python.

Python Prompt Toolkit prompt_toolkit is a library for building powerful interactive command line applications in Python. Read the documentation on rea

prompt-toolkit 8.1k Jan 4, 2023
A CLI tool to build beautiful command-line interfaces with type validation.

Piou A CLI tool to build beautiful command-line interfaces with type validation. It is as simple as from piou import Cli, Option cli = Cli(descriptio

Julien Brayere 310 Dec 7, 2022
A minimal and ridiculously good looking command-line-interface toolkit

Proper CLI Proper CLI is a Python package for creating beautiful, composable, and ridiculously good looking command-line-user-interfaces without havin

Juan-Pablo Scaletti 2 Dec 22, 2022
Terminalcmd - a Python library which can help you to make your own terminal program with high-intellegence instruments

Terminalcmd - a Python library which can help you to make your own terminal program with high-intellegence instruments, that will make your code clear and readable.

Dallas 0 Jun 19, 2022
sane is a command runner made simple.

sane is a command runner made simple.

Miguel M. 22 Jan 3, 2023
A Python based command line ARP Spoofer utility, which takes input as arguments for the exact target IP and gateway IP for which you wish to Spoof ARP request

A Python based command line ARP Spoofer utility, which takes input as arguments for the exact target IP and gateway IP for which you wish to Spoof ARP request

Abhinandan Khurana 1 Feb 10, 2022
Flashcards - A flash card application with 2 optional command line arguments

Flashcards A flash card application with 2 optional command line arguments impor

Özgür Yildirim 2 Jul 15, 2022
GetRepo-py is a command line client that queries GitHub API and searches repositories by given arguments

GetRepo-py is a command line client that queries GitHub API and searches repositories by given arguments

Davidcin 3 Feb 14, 2022
Motion detector, Full body detection, Upper body detection, Cat face detection, Smile detection, Face detection (haar cascade), Silverware detection, Face detection (lbp), and Sending email notifications

Security camera running OpenCV for object and motion detection. The camera will send email with image of any objects it detects. It also runs a server that provides web interface with live stream video.

Peace 10 Jun 30, 2021
This repo is about implementing different approaches of pose estimation and also is a sub-task of the smart hospital bed project :smile:

Pose-Estimation This repo is a sub-task of the smart hospital bed project which is about implementing the task of pose estimation ?? Many thanks to th

Max 11 Oct 17, 2022
A command-line based, minimal torrent streaming client made using Python and Webtorrent-cli. Stream your favorite shows straight from the command line.

A command-line based, minimal torrent streaming client made using Python and Webtorrent-cli. Installation pip install -r requirements.txt It use

Jonardon Hazarika 17 Dec 11, 2022
Tidier - a simple command line tool that helps you make your files tidy up

Tidier - a simple command line tool that helps you make your files tidy up

AmirMohammad Hosseini Nasab 8 Aug 16, 2022
Command line parser for common log format (Nginx default).

Command line parser for common log format (Nginx default).

Lucian Marin 138 Dec 19, 2022