Argument syntax

Typin supports an argument syntax which is based on the POSIX standard. To be fair, nobody really knows what the standard is about and very few tools actually follow it to the letter, so for the purpose of having dashes and spaces, Typin is using the "standard command line syntax".

In Typin arguments in both interactive and normal modes are splitted with CommandLineSplitter utility class. This ensures a consistent argument delimiting and escaping across all platforms.

Since options cannot have their name or short name starting with a digit, negative number values are also supported.

More specifically, the following examples are all valid:

• myapp --foo bar sets option "foo" to value "bar"
• myapp --foo -2 sets option "foo" to value -2
• myapp -o 2.4 sets option 'o' to value 2.4
• myapp -f bar sets option 'f' to value "bar"
• myapp --switch sets option "switch" without value
• myapp -s sets option 's' without value
• myapp -abc sets options 'a', 'b' and 'c' without value
• myapp -xqf bar sets options 'x' and 'q' without value, and option 'f' to value "bar"
• myapp -i file1.txt file2.txt sets option 'i' to a sequence of values "file1.txt" and "file2.txt"
• myapp -i file1.txt -i file2.txt sets option 'i' to a sequence of values "file1.txt" and "file2.txt"
• myapp cmd abc -o routes to command cmd (assuming it exists) with parameter abc and sets option 'o' without value

Argument parsing in Typin aims to be as deterministic as possible, ideally yielding the same result no matter the context. The only context-sensitive part in the parser is the command name resolution which needs to know what commands are available in order to discern between arguments that correspond to the command name and arguments which are parameters.

An option is always parsed the same way, regardless of the arity of the actual property it's bound to. This means that myapp -i file1.txt file2.txt will always be parsed as an option set to multiple values, even if the underlying property is not enumerable. For the same reason, unseparated arguments such as myapp -ofile will be treated as five distinct options 'o', 'f', 'i', 'l', 'e', instead of 'o' being set to "file".

Because of these rules, order of arguments is semantically important and it always goes like this:

{directives} {command name} {parameters} {options}

The above design makes the usage of your applications a lot more intuitive and predictable, providing a better end-user experience.