QPQ-AG/getopt
10
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Switch to rebar3

Browse Source
This commit is contained in:
Juan Jose Comellas 2017-11-01 15:55:20 -03:00
parent fe027dc097
commit 1566e7d69f
4 changed files with 98 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
Makefile
View File

@ -1,32 +1,24 @@
APPLICATION := getopt APPLICATION := getopt
REBAR=$(shell which rebar || echo ./rebar) .PHONY: all clean compile dialyzer edoc shell test
ERL := erl
EPATH := -pa ebin
DIALYZER=dialyzer
DIALYZER_OPTS=-Wno_return -Wrace_conditions -Wunderspecs -Wno_undefined_callbacks --fullpath
.PHONY: all clean compile console dialyze doc test
all: compile all: compile
clean: clean:
@$(REBAR) clean @rebar3 clean
compile: compile:
@$(REBAR) compile @rebar3 compile
console: dialyzer: compile
$(ERL) -sname $(APPLICATION) $(EPATH) @rebar3 dialyzer
dialyze: compile edoc:
@$(DIALYZER) $(DIALYZER_OPTS) -r ./ @rebar3 edoc
doc: shell:
@$(REBAR) doc @rebar3 shell
test: test:
@erl -make @rebar3 eunit
@$(ERL) -sname $(APPLICATION) $(EPATH) -noinput -s getopt_test test -s init stop

85
README.md
View File

@ -8,31 +8,28 @@ Requirements
------------ ------------
You should only need a somewhat recent version of Erlang/OTP. The module has You should only need a somewhat recent version of Erlang/OTP. The module has
been tested with Erlang R13B, R14B, R15B and R16B. been tested with all versions of Erlang starting with R13B and ending with 20.
You also need a recent version of [rebar](http://github.com/rebar/rebar) in
the system path. If you're going to run the unit tests you need the latest
version of rebar to make sure that the latest version of *getopt* is being
used. rebar already includes a compiled copy of the ``getopt`` module in its
own binary file and will give precedence to its own modules over the ones in
the project.
You also need a recent version of [rebar3](http://www.rebar3.org/) in
the system path.
Installation Installation
------------ ------------
To compile the module you simply run ``make``. To compile the module you simply run `rebar3 compile`.
To run the unit tests run ``make test``. To run the unit tests run `rebar3 eunit`.
To run the example module run ``make example``. To build the (very) limited documentation run `rebar edoc`.
To build the (very) limited documentation run ``make doc``.
After the module is compiled with ``make``, insert getopt into the Erlang lib directory (e.g. by soft link or copying).
To use getopt in your project you can just add it as a dependency in your
`rebar.config` file in the following way:
```sh ```sh
ln -s . /usr/local/lib/erlang/lib/getopt-0.8.2 {deps,
[
{getopt, "1.0.0"}
]
}
``` ```
@ -56,7 +53,7 @@ usage([{Name, Short, Long, ArgSpec, Help}], ProgramName :: string(),
CmdLineTail :: string(), OptionsTail :: [{string(), string}]) -> ok CmdLineTail :: string(), OptionsTail :: [{string(), string}]) -> ok
``` ```
The ``parse/2`` function receives a list of tuples with the command line option The `parse/2` function receives a list of tuples with the command line option
specifications. The type specification for the tuple is: specifications. The type specification for the tuple is:
```erlang ```erlang
@ -77,11 +74,11 @@ specifications. The type specification for the tuple is:
The elements of the tuple are: The elements of the tuple are:
- ``Name``: name of the option. - `Name`: name of the option.
- ``Short``: character for the short option (e.g. $i for -i). - `Short`: character for the short option (e.g. $i for -i).
- ``Long``: string for the long option (e.g. "info" for --info). - `Long`: string for the long option (e.g. "info" for --info).
- ``ArgSpec``: data type and optional default value the argument will be converted to. - `ArgSpec`: data type and optional default value the argument will be converted to.
- ``Help``: help message that is shown for the option when ``usage/2`` is called. - `Help`: help message that is shown for the option when `usage/2` is called.
e.g. e.g.
@ -89,16 +86,16 @@ e.g.
{port, $p, "port", {integer, 5432}, "Database server port"} {port, $p, "port", {integer, 5432}, "Database server port"}
``` ```
The second parameter receives the list of arguments as passed to the ``main/1`` The second parameter receives the list of arguments as passed to the `main/1`
function in escripts or the unparsed command line as a string. function in escripts or the unparsed command line as a string.
If the function is successful parsing the command line arguments it will return If the function is successful parsing the command line arguments it will return
a tuple containing the parsed options and the non-option arguments. The options a tuple containing the parsed options and the non-option arguments. The options
will be represented by a list of key-value pairs with the ``Name`` of the will be represented by a list of key-value pairs with the `Name` of the
option as *key* and the argument from the command line as *value*. If the option option as *key* and the argument from the command line as *value*. If the option
doesn't have an argument, only the atom corresponding to its ``Name`` will be doesn't have an argument, only the atom corresponding to its `Name` will be
added to the list of options. For the example given above we could get something added to the list of options. For the example given above we could get something
like ``{port, 5432}``. The non-option arguments are just a list of strings with like `{port, 5432}`. The non-option arguments are just a list of strings with
all the arguments that did not have corresponding options. all the arguments that did not have corresponding options.
e.g. Given the following option specifications: e.g. Given the following option specifications:
@ -121,13 +118,13 @@ And this command line:
Args = "-h myhost --port=1000 -x myfile.txt -vvv dummy1 dummy2" Args = "-h myhost --port=1000 -x myfile.txt -vvv dummy1 dummy2"
``` ```
Which could also be passed in the format the ``main/1`` function receives the arguments in escripts: Which could also be passed in the format the `main/1` function receives the arguments in escripts:
```erlang ```erlang
Args = ["-h", "myhost", "--port=1000", "-x", "file.txt", "-vvv", "dummy1", "dummy2"]. Args = ["-h", "myhost", "--port=1000", "-x", "file.txt", "-vvv", "dummy1", "dummy2"].
``` ```
The call to ``getopt:parse/2``: The call to `getopt:parse/2`:
```erlang ```erlang
getopt:parse(OptSpecList, Args). getopt:parse(OptSpecList, Args).
@ -145,7 +142,7 @@ Will return:
["dummy1","dummy2"]}} ["dummy1","dummy2"]}}
``` ```
The ``tokenize/1`` function will separate a command line string into The `tokenize/1` function will separate a command line string into
tokens, taking into account whether an argument is single or double tokens, taking into account whether an argument is single or double
quoted, a character is escaped or if there are environment variables to quoted, a character is escaped or if there are environment variables to
be expanded. e.g.: be expanded. e.g.:
@ -160,10 +157,10 @@ Will return something like:
["--name","John Smith","--path","John's Files","-u","jsmith"] ["--name","John Smith","--path","John's Files","-u","jsmith"]
``` ```
The other functions exported by the ``getopt`` module (``usage/2``, ``usage/3`` The other functions exported by the `getopt` module (`usage/2`, `usage/3`
and ``usage/4``) are used to show the command line syntax for the program. and `usage/4`) are used to show the command line syntax for the program.
For example, given the above-mentioned option specifications, the call to For example, given the above-mentioned option specifications, the call to
``getopt:usage/2``: `getopt:usage/2`:
```erlang ```erlang
getopt:usage(OptSpecList, "ex1"). getopt:usage(OptSpecList, "ex1").
@ -180,7 +177,7 @@ Will show (on *standard_error*):
-v Verbosity level -v Verbosity level
<file> Output file <file> Output file
This call to ``getopt:usage/3`` will add a string after the usage command line: This call to `getopt:usage/3` will add a string after the usage command line:
```erlang ```erlang
getopt:usage(OptSpecList, "ex1", "[var=value ...] [command ...]"). getopt:usage(OptSpecList, "ex1", "[var=value ...] [command ...]").
@ -197,7 +194,7 @@ Will show (on *standard_error*):
-v, --verbose Verbosity level -v, --verbose Verbosity level
<file> Output file <file> Output file
Whereas this call to ``getopt:usage/3`` will also add some lines to the options Whereas this call to `getopt:usage/3` will also add some lines to the options
help text: help text:
```erlang ```erlang
@ -223,7 +220,7 @@ Will show (on *standard_error*):
Command-line Syntax Command-line Syntax
------------------- -------------------
The syntax supported by the ``getopt`` module is very similar to that followed The syntax supported by the `getopt` module is very similar to that followed
by GNU programs, which is described [here](http://www.gnu.org/s/libc/manual/html_node/Argument-Syntax.html). by GNU programs, which is described [here](http://www.gnu.org/s/libc/manual/html_node/Argument-Syntax.html).
Options can have both short (single character) and long (string) option names. Options can have both short (single character) and long (string) option names.
@ -248,16 +245,16 @@ Argument Types
-------------- --------------
The arguments allowed for options are: *atom*; *binary*; *boolean*; *float*; *integer*; *string*. The arguments allowed for options are: *atom*; *binary*; *boolean*; *float*; *integer*; *string*.
The ``getopt`` module checks every argument to see if it can be converted to its The `getopt` module checks every argument to see if it can be converted to its
correct type. correct type.
In the case of boolean arguments, the following values (in lower or In the case of boolean arguments, the following values (in lower or
upper case) are considered ``true``: *true*; *t*; *yes*; *y*; *on*; *enabled*; *1*. upper case) are considered `true`: *true*; *t*; *yes*; *y*; *on*; *enabled*; *1*.
These ones are considered ``false``: *false*; *f*; *no*; *n*; *off*; *disabled*; *0*. These ones are considered `false`: *false*; *f*; *no*; *n*; *off*; *disabled*; *0*.
Numeric arguments can only be negative when passed as part of an assignment expression. Numeric arguments can only be negative when passed as part of an assignment expression.
e.g. ``--increment=-100`` is a valid expression; whereas ``--increment -100`` is invalid e.g. `--increment=-100` is a valid expression; whereas `--increment -100` is invalid
Implicit Arguments Implicit Arguments
@ -307,7 +304,7 @@ Positional Options
We can also have options with neither short nor long option names. In this case, We can also have options with neither short nor long option names. In this case,
the options will be taken according to their position in the option specification the options will be taken according to their position in the option specification
list passed to ``getopt:/parse2``. list passed to `getopt:/parse2`.
For example, with the following option specifications: For example, with the following option specifications:
@ -320,7 +317,7 @@ OptSpecList =
]. ].
``` ```
This call to ``getopt:parse/2``: This call to `getopt:parse/2`:
```erlang ```erlang
getopt:parse(OptSpecList, "-x mydb file.out dummy dummy"). getopt:parse(OptSpecList, "-x mydb file.out dummy dummy").
@ -337,7 +334,7 @@ Will return:
Option Terminators Option Terminators
------------------ ------------------
The string ``--`` is considered an option terminator. This means that all the The string `--` is considered an option terminator. This means that all the
command-line arguments after it are considered non-option arguments and will be command-line arguments after it are considered non-option arguments and will be
returned without being evaluated even if they follow the *getopt* syntax. returned without being evaluated even if they follow the *getopt* syntax.
@ -354,7 +351,7 @@ will return:
["--dbname","mydb","dummy"]}} ["--dbname","mydb","dummy"]}}
``` ```
Notice that the *dbname* option was assigned the value ``users`` instead of ``mydb``. Notice that the *dbname* option was assigned the value `users` instead of `mydb`.
This happens because the option terminator prevented *getopt* from evaluating it This happens because the option terminator prevented *getopt* from evaluating it
and the default value was assigned to it. and the default value was assigned to it.
@ -362,7 +359,7 @@ and the default value was assigned to it.
Non-option Arguments Non-option Arguments
-------------------- --------------------
The single ``-`` character is always considered as a non-option argument. The single `-` character is always considered as a non-option argument.
e.g. This invocation using the specification list from the previous example: e.g. This invocation using the specification list from the previous example:

BIN
rebar vendored
View File

Binary file not shown.

13
rebar.config
View File

@ -14,4 +14,17 @@
warn_untyped_record, debug_info, warn_untyped_record, debug_info,
{platform_define, "^2", unicode_str} {platform_define, "^2", unicode_str}
]}. ]}.
{dialyzer,
[
{warnings, [no_return, no_undefined_callbacks, no_unused]},
{get_warnings, true},
{plt_apps, top_level_deps},
{plt_location, local},
{base_plt_apps, [kernel, stdlib, sasl, inets, crypto, public_key, ssl,
runtime_tools, erts, compiler, tools, syntax_tools, hipe,
mnesia]},
{base_plt_location, global}
]}.
{xref_checks, [undefined_function_calls]}. {xref_checks, [undefined_function_calls]}.