Tips

A few common parameters are available that are not specifically listed as optional parameters for each action: help, verbose, debug, quiet, special, dateFormat, dateFormat2, and outputType. Similarly for database related parameters that are optional for all get list actions: url, dbUser, dbPassword, database, driver, dbJar, host, port, dbCreateTable, dbTable, dbTableKeys, afterSql, and propertyFile.

• To get help for a specific action, type the action followed by --help - example: --action getProjectList --help
• Use double dash for multi-letter parameters - example: --help
• Use single dash for single letter parameters indicated in the Short column in parameter help - example: -v
• When parameters are specified, most need a value as indicated by a check in the Value column in parameter help - example: --action addPage
• Some parameters are flags (boolean) and must not be followed by a value - example: --verbose
• Parameter names are case sensitive, but, action values are not - example: --userid is invalid but --action addpage is equivalent to --action addPage
  • An incorrect case parameter will result in an unknown parameter error and show action help with correctly cased parameter (9.8 or higher)
• Some parameters become required once a specific action is chosen. This is indicated in the action help text as required.
• Some parameters have both short (one letter) and long (more than one letter) parameter names - example: -a or --action are the same and cannot both be specified
• Some parameters have default values, if so, they are indicated in the help text
• Values that contain blanks or some special characters (platform specific) must be enclosed by double quotes - example: --title "this is my title"
• Quoting rules in commands can vary by terminal environment:
  • Windows command terminals or run action scripts for all platforms: embedded double quotes within a double quoted string must be escaped by doubling the double quote - example: –common "-a addComment --comment ""This is an example of a double quoted string inside a double quote"" "
  • Linux and Mac/OSX command terminals require standard Linux style escaping: embedded double quotes within a double quoted string can be escaped with a \ - example: –common " -a addComment  --comment  \"This is an example of a double quoted string inside a double quote\" "
  • Run CLI Actions usage: embedded double quotes within a double quoted string can be escaped by doubling the double quote (first example above)
  • A single quote sometimes can used in place of a double quotes on some command terminal environments - example: –common '-a addComment --comment "This is an example of a double quoted string inside a double quote" '
• Some parameters allow entry of a comma separated list of values, values containing a comma must be enclosed in single quotes - example: --custom "'first:a,b,c', second:x". Embedded single quotes within a quoted string must be doubled
• Some text fields support the automatic conversion of " \n " (blanks are significant) to be replaced with a new line character - example: --description "A multi-line text field: \n # line 1 \n # line 2"

Some special characters are difficult to deal with or make action text very complicated. This is because they have special meaning in either the OS command terminal handling, the tool's command line parsing, or the tool's use of separators (like comma or colon separated lists). As a convenience to avoid some of these nasty situations, a special parameter was implemented to allow alternate characters to be used instead of (or in addition to) the problematic characters within parameter values. The choice of what special characters to use depends on the content so that you do not have conflicts with intended content. The special parameter works by the user providing a order specific alternate character. The alternative character is replaced with the real character after all other parsing occurs. It is implemented for many action parameters that are problematic in this area. Not all situations are covered, but, that will improve as other use cases are identified.

A blank in any position is ignored (no alternate provided).

Example: –special " #  ~" provides alternates for colon and double quote. 

         --common "--findReplace ~something to find containing a : (colon)#replacement~"  

User and password values should be in the ISO-8859-1 character set. Also avoid characters that require escaping on your OS command terminal. Non standard characters will result in an authorization error similar to: User is not authorized to perform the request.