Download the PHP package douglasgreen/optparser without Composer

On this page you can find all versions of the php package douglasgreen/optparser. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package optparser

optparser

OptParser is a replacement for using the built-in getopt() to get command-line options in PHP programs. It's better than getopt because:

Commands

A program accepts one or more types of usage. A usage is a series of options.

Options

An option is one of the following:

If there is a command, there can only be one command per usage and it must come first. If there are more than one usage, each usage must have a command to distinguish it.

If there are terms, they are required and must follow the command, if any.

Parameters and flags come last. The order is important to avoid ambiguity.

Commands and terms are required, because they are positional, but parameters and flags are optional, because they are named.

Naming convention

Commands, flags, and parameters must all follow the Unix convention for their names:

That is also known as kebab case. An example name is file-path.

Command matching

Each usage is distinguished by its command. Each command is different and so only one usage can possibly match at runtime.

Argument aliases

Each argument can have one or more aliases. If an alias is short (only one character), it is invoked with a single hyphen like -h. If an alias is long (more than one character), it is invoked with two hyphens like --help.

Each alias must be defined only once.

Argument names

Every argument must have at least one long alias. The first long alias that is specified for that argument is used as the argument name. You must retrieve the argument using its name.

Commands, parameters, and flags can have aliases. But a term is not marked so it only has a name, not aliases.

Argument types

Most of the list of permitted argument types was taken from the list of PHP validation filters. Some custom types were added. Permitted types include:

These are specified as the second argument of OptParser::addParam() and OptParser::addTerm(), because parameters and terms accept arguments and therefore have type. These types are printed in program help and applied automatically during argument processing, resulting in program error and termination on failure to validate.

Argument filters

You can define your own filter callback as the last argument of OptParser::addParam() and OptParser::addTerm() also. The filter can do custom validation. If validation succeeds, you can return the original value or a filtered version of it. If validation fails, throw a BadArgumentException with a descriptive error message, and the program will error and terminate.

Formatting

Flags can be combined, for example -a -b -c can be written as -abc. However a combined flag can't take arguments.

A space or equal sign must separate every flag or parameter from its argument.

The argument list can be terminated by --, which can be followed by non-options. The program ignores non-options but returns them with the matched usage. You can retrieve them using OptResult::getNonoptions().

Fetching results

Results are returned by OptParser::parse() as an OptResult object which I call $input as it represents user input.

You can retrieve matched arguments from the user with $input->get($name), where name was the option name. You can also retrieve arguments with as attributes with $input->$name. Camel case in the attribute names is mapped to kebab case in option names. For example, $input->filePath would map to the file-path option name.

Program interface

To use OptParser:

  1. Create an OptParser instance with the name and description of the program. This is used when displaying program help.
  2. Use chained calls on $optParser to addCommand(), addTerm(), addParam(), and addFlag() to define those types of options.
  3. Combine the options together into usages by calling $optParser->addUsage() to add a specific combination of option names. If there is only one usage, you can call the simpler $optParser->addUsageAll() to add all the options at once.
  4. Parse the arguments with $input = $optParser->parse();.
  5. Get the command executed with $command = $input->getCommand(); to determine how to interpret output.
  6. Fetch each option name for the current command with $input->get($name) or the more concise $input->$name.

Sample usage

There is a sample usage in a file. You can also run the program with -h to see sample help output.

Sample help

The sample help output looks like this:

This shows:

Frequently Asked Questions

Why use OptParser instead of getopt()?

OptParser supports positional arguments, does error checking, and prints a well-formatted help message. getopt() doesn't do these things.

What option type should I use?

Commands are just there to distinguish between usages. If you have two or three arguments of different type that you won't confuse, then you can make them terms. But mostly you should give options names like parameters, which take an argument, and flags, which don't. Named options are harder to confuse.

What's the difference between addUsage() and addUsageAll()?

OptParser::addUsageAll() is for the simple case when you only have one usage. Call this function to add all terms, parameters, and flags without having to repeat their names. OptParser::addUsage() is for the case when you have multiple commands. Call this function to add each command with its associated terms, parameters, and flags by name.

Developer setup

See Setup Guide for steps to set up for development.


All versions of optparser with dependencies

PHP Build Version
Package Version
Requires php Version >=8.1
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package douglasgreen/optparser contains the following files

Loading the files please wait ....