Common parameters

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.

Tips

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"
In run scripts and automations:
- Lines with lead # are treated as comments and are logged when run
- Lines with lead ## are treated as comments and NOT logged when run (12.1 and higher)

Special parameter

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.

Position	Character	Character name	Suggested alternate	Usage
1	,	comma		Some parameters use comma separated lists.
2	:	colon	#	Some parameters use colon separated values.
3	@	at sign		Replacement variables syntax: @...@.
4	'	single quote		Used in separated lists to cover cases where content contains separator.
5	"	double quote	~	Parameters containing blanks.
6	^	caret		Substitution double quote indicator: ^^...^^. See ACLI-673 for details.

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~"

Character Set

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.

Browser not supported