yangcli-pro CLI Reference

--aliases-file

The --aliases-file parameter specifies the yangcli-pro command aliases file specification to use.

leaf aliases-file {
  type string;
  default "~/.yumapro/.yangcli_pro_aliases";
}

Syntax	string
Default:	$HOME/.yumapro/.yangcli_pro_aliases
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --aliases-file=~/myalaises

--allow-shell

The -–allow-shell parameter specifies whether the run-shell command will be allowed or not.

Warning

Enabling shell access from yangcli-pro can be a security risk. Th run-shell operation is disabled by default.

leaf allow-shell {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro –allow-shell=true

--ask-password

The --ask-password parameter controls whether the user will be prompted for a password for the connect command. This parameter is intended to support servers that use keys for authentication instead of passwords.

If 'true' then the connect command will expect that a password is needed. The --no-password parameter can still be used in the connect command instead of providing a password.
If 'false' the connect command will not require a password, but it will use the password parameter if it is set.

leaf ask-password {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --ask-password=false

--auto-discard-changes

The --auto-discard-changes parameter controls whether the <discard-changes> operation will be automatically sent when errors occur for the edit and save mode.

If true, discard-change will be automatically sent.
If false, discard-change will not be automatically sent.

leaf auto-discard-changes {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --auto-discard-changes=true

--autoeventhandlers

The --autoeventhandlers parameter controls whether the saved event_handlers will be loaded into memory at startup and saved to file at exit.

If true, the default event-handler-cfg file will be used (~/.yumapro/.yangcli_pro_event_handlers.conf) for loading and saving the configured event-handlers in memory.
If false, the configured event-handlers will only be stored and loaded manually with the event-handlers-cfg command.

leaf autoeventhandlers {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoeventhandlers=false

--auto-keepalive

The --auto-keepalive parameter is intended to keep NETCONF over SSH sessions from getting dropped.

Warning

This parameter is NOT IMPLEMENTED. IT IS IGNORED.

This parameter is not really needed since the functionality is available at the SSH layer.

The SSH server can be configured to send keep alive messages to the SSH client using the sshd_config configuration parameters:
- TCPKeepAlive This parameter is recommended to prevent undetected lost TCP sessions. It is enabled by default.
- ClientAliveCountMax This parameter controls how many keepalive messages can be missed in a row from the client before the session is dropped.
- ClientAliveInterval This parameter controls how often keep alive messages are sent to the client. The default is not to send them at all.
The SSH client can be configured to send keep alive messages to the SSH server using the ssh_config configuration parameters:
- TCPKeepAlive This parameter is recommended to prevent undetected lost TCP sessions. It is enabled by default.
- ServerAliveCountMax This parameter controls how many keepalive messages can be missed in a row from the server before the session is dropped.
- ServerAliveInterval This parameter controls how often keep alive messages are sent to the server. The default is not to send them at all.

leaf auto-keepalive {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --auto-keepalive=true

--auto-reconnect

The --auto-reconnect parameter controls whether yangcli-pro will try to reconnect to the server If the session gets dropped by the server.

If 'true', yangcli-pro will try to reconnect to the server.
If 'false', yangcli-pro will not try to reconnect to the server.

 leaf auto-reconnect {
   type boolean;
   default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --auto-reconnect=false

--auto-reconnect-interval

The --auto-reconnect-interval parameter indicates the number of seconds yangcli-pro will wait to re-establish a connection if a session is dropped and the server becomes unreachable. The default is 10 seconds.

leaf auto-reconnect-interval {
  type uint16 { range "1 .. 3600"; }
  units seconds;
  default 10;
}

Syntax	uint16
Default:	10
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --auto-reconnect-interval =15

--auto-reconnect-max

The --auto-reconnect-max parameter controls the number of times to retry the connection. Zero means no limit, otherwise re-connect attempts will stop after this number of failures. The default is 5 times.

leaf auto-reconnect-max {
  type uint16;
  default 5;
}

Syntax	uint16
Default:	5
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --auto-reconnect-max=3

--autoaliases

The --autoaliases parameter controls automatic loading and saving of the command aliases file.

If 'true', the 'aliases-file' parameter will be used if it is set, or else the default aliases file will be used (~/.yumapro/.yangcli_pro_aliases), for loading and saving the yangcli-pro command aliases.
If 'false', the yangcli-pro command aliases will only be stored and loaded manually with the aliases command.

leaf autoaliases {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoaliases=false

--autocomp

The --autocomp parameter controls automatic completion of command and parameter names.

If true, then the program will attempt to find a partial match by comparing only the number of characters entered. For example '--log-l=debug' is the same as '--log-level=debug'.

If 'false', then command and parameter names must match exactly.

leaf autocomp {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autocomp=false

--autoconfig

The --autoconfig parameter controls whether the running configuration will be retrieved automatically for active sessions.

By default, the running config will not be retrieved and maintained. This option must be set to true to support value-node command tab completion.

If true, then the program will attempt to retrieve and maintain a shadow configuration for each session, using the NETCONF <get-config> operation.
If 'false', then automatic shadow configuration handling will not be done.

leaf autoconfig {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoconfig=true

--autoconfig-conf-mode

The --autoconfig-conf-mode parameter controls whether the running configuration will be retrieved automatically for active sessions in config-mode.

This parameter must be set to 'true' to support value node tab completion in config mode.

If --autoconfig is set to 'true' then autoconfig-conf-mode is ignored and autoconfig will be done for config mode.
If --autoconfig is set to 'false' then autoconfig-conf-mode is checked
- If 'true', the autoconfig updates after each update will be done. The current config will be available to assist tab completion.
- If 'false', the autoconfig updates after each update will not be done. The current config will not be available to assist tab completion.

leaf autoconfig-conf-mode {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoconfig-conf-mode=false

--autodevices

The --autodevices parameter controls whether the saved devices will be loaded into memory at startup and saved to file at exit.

If 'true', the default device-cfg file will be used (~/.yumapro/.yangcli_pro_devices.conf) for loading and saving the configured devices in memory.
If 'false', the configured devices will only be stored and loaded manually with the devices-cfg command.

leaf autodevices {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autodevices=false

--autohistory

The --autohistory parameter controls automatic loading and saving of the command line history buffer in the yangcli-pro program.. The default location for this file is ~/.yumapro/.yangcli_pro_history.

If 'true', then when the program starts, the default command line history buffer will be loaded, and the previous set of commands will be available with the history and recall commands. The --history-file parameter specifies which file is used to load and save the command line history.
If 'false', then the command line history buffer will not be loaded and saved automatically.

leaf autohistory {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autohistory=false

--autoload

The --autoload parameter controls automatic loading of session YANG modules, as needed.

If 'true', then the program will attempt to find a needed YANG module.
If 'false', then YANG modules must be loaded manually.

leaf autoload {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoload=false

--autoload-cache

The --autoload-cache parameter controls whether the modules retrieved with the <get-schema> operation are cached for use by the running instance of yangcli-pro.

If 'true', then the YANG modules that are retrieved with the <get-schema> operation will be cached. A cached module will be used by yangcli-pro instead of calling <get-schema>, if that module revision is requested again.
If 'false', then the YANG modules that are retrieved with the <get-schema> operation will not be cached.

leaf autoload-cache {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoload=false

--autoload-get

The --autoload-get parameter controls whether the <get> operation will be used to retrieve the /netconf-state/schemas sub-tree.

This option is needed to autoload sub-modules that are not available to yangcli-pro, since YANG submodules are not advertised in the <hello> message. The value 'true' should be used.

If 'true', then the schema list will be used instead of the <hello> message module capabilities, if the server supports the 'ietf-netconf-monitoring' module.
If 'false', then just the <hello> message module list will be used to retrieve YANG modules with the <get-schema> operation.

leaf autoload-get {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoload=false

--autoload-save-cache

The --autoload-save-cache parameter controls whether the modules held in the YANG module cache are saved when yangcli-pro exits, as needed.

If true, then the YANG modules that are cached will be saved when yangcli-pro exits.
If false, then the YANG modules that are cached will not be saved when yangcli-pro exits.

leaf autoload-save-cache {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoload-save-cache=false

--autonotif

The --autonotif parameter controls whether notifications will automatically be enabled when a session starts, if the server supports the :notification and :interleave capabilities.

By default, notifications will not be enabled. If enabled, a <create-subscription> operation will be performed when the session starts, and notification events for the session will be monitored.

This parameter does not affect echoing of notification messages. The --echo-notifs and --echo-notif-loglevel parameters need to be set appropriately to echo received notification messages.

If 'true', then the program will attempt to start a notification subscription if the server advertises support, using the <create-subscription> NETCONF operation.
If 'false', then notification subscriptions must be started manually.

leaf autonotif {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autonotif=true

--autonvsave

The --autonvsave parameter controls whether the save and apply commands will NV-save the configuration changes or not. If the server advertises the :startup capability and this variable is set to 'false', then the final step to save running to startup will not be done.

The nvsave command can be used to manually save the running datastore to non-volatile memory (startup datastore). If this parameter is set to 'true' the final step of saving the running datastore to the startup datastore will be done.

leaf autonvsave {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autonvsave=false

--autoschemaservers

The --autoschemaservers controls whether the saved schema servers will be loaded into memory at startup and saved to file at exit.

If true, the default Schema Server Config file will be used (~/.yumapro/.yangcli_pro_schemaservers .conf) for loading and saving the configured schema servers in memory.
If false, the configured schema servers will only be stored and loaded manually with the schema-server-cfg command.

leaf autoschemaservers {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autoschemaservers=false

--autosessions

The --autosessions parameter controls whether the saved sessions will be loaded into memory at startup and saved to file at exit.

If true, the default session-cfg file will be used (~/.yumapro/.yangcli_pro_sessions.conf) for loading and saving the configured sessions in memory.
If false, the configured sessions will only be stored and loaded manually with the sessions-cfg command.

leaf autosessions {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autosessions=false

--autotest

The --autotest parameter controls whether the saved test suites will be loaded into memory at startup and saved to file at exit.

If true, the default test-suite-cfg file will be used (~/.yumapro/.yangcli_pro_tests.conf) for loading and saving the configured test-suites in memory.
If false, the configured test-suites will only be stored and loaded manually with the test-suite command.

leaf autotest {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autotest=false

--autousers

The --autousers parameter controls whether the saved sessions will be loaded into memory at startup and saved to file at exit.

If true, the default users-cfg file will be used (~/.yumapro/.yangcli_pro_users.conf) for loading and saving the configured users in memory.
If false, the configured sessions will only be stored and loaded manually with the users-cfg command.

leaf autousers {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autousers=false

--autouservars

The --autouservars parameter controls whether the yangcli-pro user variables will be saved at exit and loaded at startup.

If 'true', the 'uservars-file' parameter will be used if set, or else the default user variables file will be used (~/.yumapro/yangcli_pro_uservars.xml), for loading and saving the yangcli-pro user variables.
If 'false', the yangcli-pro user variables will only be stored and loaded manually with the uservars command.

leaf autouservars {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --autouservars=false

--bad-data

The --bad-data parameter controls how invalid parameter input is handled by the program.

ignore: Use invalid parameter values. Use with caution.
warn: Issue a warning message, but use the invalid data anyway.
check: Prompt the user interactively, and check if the invalid data should be used, or a new value re-entered.
error: Do not use invalid parameter values. Prompt the user to re-enter the invalid value.

leaf bad-data {
  type enumeration {
    enum ignore {
    }
    enum warn {
    }
    enum check {
    }
    enum error {
    }
  }
  default "check";
}

Syntax	enumeration: ignore warn check error
Default:	check
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --bad-data=warn

--batch-mode

The --batch-mode parameter specifies that the interactive CLI will not be used.

If present, the interactive CLI will not be used. A script should be provided with the --run-script parameter, or a command provided with the --run-command parameter, or else the program will simply exit.

leaf batch-mode {
   type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --batch-mode --run-script=~/run-tests

--break-key-mode

The --break-key-mode parameter specifies the behavior when the break key is pressed during a command. The default mode is 'program' to maintain backward compatibility.

program
- Break key will cause the program to exit no matter what mode or state the program is in at the moment.
command
- Break key will cause the current command in the current session to be terminated.

If no command is in progress, or currently in config mode or enable mode, then the break key will have no effect.

leaf break-key-mode {
   type enumeration {
     enum program {
     }
     enum command {
     }
   }
   default program;
}

Syntax	enum (program \| control)
Default:	program
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --break-key-mode=command

--callhome-address

The --callhome-address parameter specifies the IP address that should be used to listen for Call Home connections. Ignored if --callhome-enabled is false.

leaf callhome-address {
  type inet:ip-address;
  default "0.0.0.0";
}

Syntax	Inet:ip-address
Default:	0.0.0.0
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --callhome-address=192.168.0.40

--callhome-enabled

The --callhome-enabled parameter enables the Call Home protocol.

If 'true', then yangcli-pro will listen for SSH Call Home connections on the socket identified by the --callhome-address and --callhome-port parameters.
If 'false' then the Call Home server function will not be enabled

leaf callhome-enabled {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --callhome-enabled=true

--callhome-port

The --callhome-port parameter specifies the TCP port number that should be used to listen for NETCONF over SSH Call Home connections. Ignored if --callhome-enabled is false.

leaf callhome-port {
  type inet:port-number;
  default 4334;
  reference "RFC 8071";
}

Syntax	Inet:port-number
Default:	4334
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --callhome-port=8400

--callhome-tls-port

The --callhome-tls-port parameter specifies the TCP port number that should be used to listen for NETCONF over TLS Call Home connections. Ignored if --callhome-enabled is false.

leaf callhome-tls-port {
  type inet:port-number;
  default 4335;
  reference "RFC 8071";
}

Syntax	Inet:port-number
Default:	4335
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --callhome-tls-port=8401

--callhome-user

The --callhome-user parameter specifies the name specifies the name of a configured user entry that should be used as the default user for Call Home sessions, if no saved session entry is found matching the server IP address. Will be ignored if the user is not currently configured.

If a Call Home session is attempted with an entry and that connection fails, then that callhome-user will not be attempted for the specific server address until yangcli-pro is restarted. This only applies if there are multiple callhome-user entries.

If only one callhome-user entry exists then it will be used every time, to be backward-compatible with previous releases.

If used in yp-client then it is possible an application callback will pick the callhome-user for a specific address.

It that case, the ordered-by user property will be ignored. Otherwise the callhome-user entries are attempted in the order they are processed from the CLI or configuration file.

leaf-list callhome-user {
  type nt:NcxUserName;
  ordered-by user;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	yangcli-pro
Example:	yangcli-pro --callhome-user=chuser1 --callhome-user=chuser2

Note that the user value is the name of a user-cfg entry, which has to be set up in advance for this parameter to have any effect.

Example user-cfg command for user “chuser1”

username: fred
password: secret1

> user-cfg create chuser1 user-name=fred password=secret1

--check-output

The --check-output parameter specifies whether <rpc> messages about to be sent to a remote server should be validated against the YANG schema for the specific RPC operation.

If true, then yangcli-pro will validate remote commands against the YANG definition for the rpc/input node. This checks the operation parameters about to be sent to a server session.

Note that validation of the contents of a <config> element is not done.

This CLI parameter is also the $$check-output global parameter.

leaf check-output {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --check-output=false

--check-output-error

The --check-output-error parameter specifies whether validation errors detected in <rpc> messages about to be sent to a remote server should be treated as warnings or errors.

If 'true', then errors found during the check-output validation tests will be treated as errors, causing the <rpc> about to be sent to fail.
If 'false', then errors found during the check-output validation tests will be treated as warnings.

This CLI parameter is also the $$check-output-error global parameter.

leaf check-output-error {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --check-output-error=true

--check-replies

The --check-replies parameter specifies whether <rpc-reply> messages received from a remote server should be validated against the YANG schema for the specific RPC operation.

Note that validation of the contents of a <config> element is not done.
This CLI parameter is also the $$check-replies global parameter.
If 'true', then yangcli-pro will validate remote commands against the YANG definition for the rpc/output node. If the “output” section is missing or empty, then the <rpc-reply> will be checked to make sure it contains either <ok> or 1 or more <rpc-error> elements.
If 'false' then <rpc-reply> messages from the server will not be validated against the rpc "output" statement for the operation.

leaf check-replies {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --check-replies=false

--check-replies-error

The --check-replies-error parameter specifies whether validation errors detected in <rpc-reply> messages received from a remote server should be treated as warnings or errors.

If 'true', then errors found during the check-replies validation tests will be treated as errors, causing the <rpc-reply> about to be processed to be rejected instead.
If 'false', then errors found during the check-replies validation tests will be treated as warnings.

This CLI parameter is also the $$check-replies-error global parameter.";

leaf check-replies-error {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --check-replies-error=true

--config-autosave

The --config-autosave parameter controls how edits in config term mode are saved to NV-storage if the server supports the :startup capability.

If 'true', automatically copy running to startup when an edit is applied.
If 'false', no automatically copy from running to startup when an edit is applied. The user will enter save or copy-config manually once config term mode is exited.

leaf config-autosave {
  description
     type boolean;
     default true;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --config-autosave=true

--config-commit-mode

The --config-commit-mode parameter controls how edits will be committed in configuration mode.

If 'true' then edits done in config mode will be made to the candidate datastore if possible. The edits will not be committed to the running datastore automatically. Instead, the config-commit command in config mode, or <commit> operation in normal mode is required to activate the edits in the server.
If 'false' then edits done in config mode will be committed to the running datastore after each apply or exit command in config mode.

The default configuration commit mode is 'false'.

leaf config-commit-mode {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --config-commit-mode=true

--config-edit-mode

The --config-edit-mode parameter controls how edits will be applied in configuration mode.

There are 3 possible editing modes:

line: The edit(s) are automatically applied after each line is entered
level: The edits(s) are automatically applied when the current level is exited
manual: The edit(s) are only applied manually with the apply command.

The default configuration editing mode is level. Note that the apply command can be used even if the value of this parameter is not manual.

leaf config-edit-mode {
  type config-edit-mode-type;
  default level;
}

Syntax	enum: line level manual
Default:	level
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --config-edit-mode=line

config-edit-mode Examples

The following examples show how the different config edit modes change how edits are applied to the target datastore on the server.

The NACM data model defined in ietf-netconf-acm.yang is used for these examples.
The starting point is the top-level (just entered config mode)
Commands:
- Create or modify a NACM group named 'group1' and then enter the 'group' list entry as a sub-mode.
- Add a 'user-name' leaf to the list entry
- Exit 4 sub-levels to exit config mode

mysession# nacm groups group group1

mysession(group)# user-name user1

mysession(group)# exit

mysession(groups)# exit

mysession(nacm)# exit

mysession# exit

mysession>

config-edit-mode='line'

mysession# nacm groups group group1

Applying 1 edit

mysession(group)#

mysession(group)# do show run

nc:rpc-reply {
  data {
    nacm:nacm {
      groups {
        group  group1 {
          name group1
        }
      }
    }
  }
}

Since the mandatory nodes are present, the edit to create the NACM group is sent right away.
The new prompt context is the '/nacm/groups/group' list entry for 'group1'.

mysession(group)# user-name user1

Applying 1 edit

mysession(group)#

mysession(group)# do show run

nc:rpc-reply {
  data {
    nacm:nacm {
      groups {
        group  group1 {
          name group1
          user-name user1
        }
      }
    }
  }
}

Since the modified field is a leaf-list, the edit to add a user-name child node to the NACM group is sent right away.
The prompt context was not changed since a new sub-mode was not entered.

config-edit-mode='level'

mysession# nacm groups group group1

mysession(group)#

mysession(group)# do show run

nc:rpc-reply {
  data {
  }
}

Even though the mandatory nodes are present, no edit to create the NACM group is sent yet.
The new prompt context is the '/nacm/groups/group' list entry for 'group1'.

mysession# user-name user1

mysession(group)#

mysession(group)# do show run

nc:rpc-reply {
  data {
  }
}

mysession(group)# do show edit

nacm:nacm {
  groups {
    group  group1 {
      name group1
      user-name user1
    }
  }
}

The edit is still pending and has not been applied yet.
The prompt context was not changed since a new sub-mode was not entered.

mysession(group)# exit

Applying 1 edit

mysession(groups)# exit

mysession(nacm)# exit

mysession# exit

mysession>

The entire 'nacm' container edit was applied at the first 'exit' command and no edits applied in the following 2 'exit' commands.
After the edit is applied the return command can be used to exit config mode instead of multiple exit commands.

config-edit-mode='manual'

mysession# nacm groups group group1

mysession#

mysession(group)# do show run

nc:rpc-reply {
  data {
  }
}

mysession# do sho edit

nacm:nacm {
  groups {
    group  group1 {
      name group1
    }
  }
}

No edit is applied even though the command line represented a complete edit.
The prompt context was not changed and a new sub-mode was not entered.

mysession# user-name user1

Error: No config object found matching 'user-name'

Warning: Config Mode Error: unknown object

A 'user-name node cannot be added this way since a sub-mode was not entered

mysession# nacm groups group group1 user-name user1

mysession#

mysession# do show edit

nacm:nacm {
  groups {
    group  group1 {
      name group1
      user-name user1
    }
  }
}

The existing edit was modified instead of creating a new list entry.

mysession# exit

Warning: Exiting config mode with edits pending.
Discarding 1 edits for session 'mysession'

nacm:nacm {
  groups {
    group  group1 {
      name group1
      user-name user1
    }
  }
}

mysession>

The edit was discarded without warning in this mode. The user is expected to be aware of the 'do show edit' command and current context level.
The apply command must be entered before exiting config mode.

--confirm-data-retries

The --confirm-data-retries parameter specifies how many retry attempts will be given to the user to correctly re-enter a Confirmed Parameter value that has the ywx:confirm-data extension.

The command in progress will be cancelled unless the data node is properly connfirmed or skipped.

leaf confirm-data-retries {
  type uint8 {
    range "1 .. 10";
  }
}

Syntax	uint8
Default:	3
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --confirm-data-retries=5

--default-module

The --default-module parameter specifies the module to search for identifiers, after the "netconf" and other modules have been checked. This allows a specific module to match identifier names first, before all modules are searched at once. This can avoid a collision if the same identifier value is used in more than one module.

leaf default-module {
   type nt:NcxName;
}

Syntax	string: module name without any path or file extension included.
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --default-module=testmod

--disable-command

The --disable-command parameter specifies a top-level command that should be disabled and not visible or available to a user. If the value does not contain a module name prefix, then the command will be disabled in all modules.

Note

If a prefix is needed then it is the YANG module prefix, not the YANG module name
If the command name is unique then no prefix is required

For example, to disable the NETCONF <delete-config> operation and the yangcli-pro list command:

--disable-command="nc:delete-config"
--disable-command="yc:list"

leaf-list disable-command {
   type nt:NcxIdentifier;
}

Syntax	nt:NcxIdentifier
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	yangcli-pro yp-shell
Example:	yangcli-pro --disable-command=nc:delete-config

--display-mode

The --display-mode parameter controls how data is displayed in the program.

The qualified names (identifiers, identityref, XPath) within a text configuration can be generated several ways. This is needed because sibling nodes in different XML namespaces can have the same name.

--display-mode values

enum value	description	example
plain	no prefix, just local-name	sysBootError
prefix	XML prefix and local-name	sys:sysBootError
module	module name and local name	system:sysBootError
xml	XML format	<sysBootError xmlns=”foo”>
xml-nons	XML format without namespace (xmlns) attributes	<sysBootError>
json	JSON format	{ “sysBootError” : “blah” }
cli	CLI format	sysBootError blah

When saving configuration files in non-volatile storage, then it is suggested that only module, json, or xml modes be used, since these are the only deterministic modes.

The set of XML prefixes in use at any one time is not persistent, and cannot be relied upon, unless the namespace declarations are saved (xml mode) or the module names are saved (module mode).

The json format uses RFC 7951 format which does not rely on XML prefixes.

leaf display-mode {
   type enumeration {
     enum plain {
     }
     enum prefix {
     }
     enum module {
     }
     enum xml {
     }
     enum xml-nons {
     }
     enum json {
     }
     enum cli {
     }
  }
  default plain;
}

Syntax	enumeration: plain prefix module xml xml-nons json cli
Default:	plain
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --display-mode=module

--display-mode Examples

In this example the server contains 4 NACM groups:

admin: admin1, admin2
guest: guest1, guest2
super: superuser1
test:

The command get-config source=running is used to show the output in different formats. The --indent parameter is set to the default (2).

--display-mode=plain

rpc-reply {
  data {
    nacm {
      groups {
        group  admin {
          name admin
          user-name admin1
          user-name admin2
        }
        group  guest {
          name guest
          user-name guest1
          user-name guest2
        }
        group  super {
          name super
          user-name superuser1
        }
        group  test {
          name test
        }
      }
    }
  }
}

--display-mode=prefix

nc:rpc-reply {
  data {
    nacm:nacm {
      groups {
        group  admin {
          name admin
          user-name admin1
          user-name admin2
        }
        group  guest {
          name guest
          user-name guest1
          user-name guest2
        }
        group  super {
          name super
          user-name superuser1
        }
        group  test {
          name test
        }
      }
    }
  }
}

--display-mode=module

yuma-netconf:rpc-reply {
  data {
    ietf-netconf-acm:nacm {
      groups {
        group  admin {
          name admin
          user-name admin1
          user-name admin2
        }
        group  guest {
          name guest
          user-name guest1
          user-name guest2
        }
        group  super {
          name super
          user-name superuser1
        }
        group  test {
          name test
        }
      }
    }
  }
}

--display-mode=xml

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
      <groups>
        <group>
          <name>admin</name>
          <user-name>admin1</user-name>
          <user-name>admin2</user-name>
        </group>
        <group>
          <name>guest</name>
          <user-name>guest1</user-name>
          <user-name>guest2</user-name>
        </group>
        <group>
          <name>super</name>
          <user-name>superuser1</user-name>
        </group>
        <group>
          <name>test</name>
        </group>
      </groups>
    </nacm>
  </data>
</rpc-reply>

--display-mode=json

{
  "yuma-netconf:rpc-reply": {
    "data": {
      "ietf-netconf-acm:nacm": {
        "groups": {
          "group": [
            {
              "name":"admin",
              "user-name": [
                "admin1",
                "admin2"
              ]
            },
            {
              "name":"guest",
              "user-name": [
                "guest1",
                "guest2"
              ]
            },
            {
              "name":"super",
              "user-name": [
                "superuser1"
              ]
            },
            {
              "name":"test"
            }
          ]
        }
      }
    }
  }
}

--display-mode=cli

rpc-reply
  data
    nacm
      groups
        group  admin
          user-name admin1
          user-name admin2
        group  guest
          user-name guest1
          user-name guest2
        group  super
          user-name superuser1
        group  test

--echo-notif-loglevel

The --echo-notif-loglevel parameter controls how unregistered notifications are echoed when notification messages are received. If the --echo-notifs parameter is true, then this parameter controls the logging debug level needed for notifications to be printed, If --echo-notifs is 'false' then this parameter has no effect.

Only notifications other than <netconf-config-change> Event are echoed. This notification is used to maintain shadow configurations.

If the --log-level is set to the same value or higher as this parameter, then the full notification message will be echoed.

If the --log-level is set to one level lower than this parameter, then a 1 line notification summary message will be echoed. For example, if --log-level=info and --echo-notifs=true and --echo-notif-loglevel=debug, then a one line summary will be printed for received notifications.

Note

The default is different on yp-shell (debug) and yangcli-pro (info). The YANG default is not used correctly

leaf echo-notif-loglevel {
  type nt:NcDebugType;
  default debug;
}

Syntax	enum: (same as log-level)
Default:	debug
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --echo-notif-loglevel=info

--echo-notifs

The --echo-notifs parameter controls whether unregistered notifications are echoed when notification messages are received, to the log or STDOUT.

If 'true', <notification> messages will be output to the log, if log-level is set to the value specified by the echo-notif-loglevel or higher.
If 'false', <notifications> messages will not be output to the log.
The $$echo-notifs system variable is derived from this parameter.
If --autonotif=true then this parameter will also be set to true.
Only notifications other than <netconf-config-change> Event are echoed. This notification is used to maintain shadow configurations.

Note

The default is different on yp-shell (false) than yangcli-pro (true). The YANG default is not used correctly.

leaf echo-notifs {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --echo-notifs=false

--echo-replies

The --echo-replies parameter controls whether <rpc-reply> messages are echoed when they are received. The $$echo-replies system variable is derived from this parameter.

If 'true' then replies with data will be displayed.
If 'false' then they will not be displayed.

Note

This parameter does not affect error replies (messages with <rpc-error> elements in them).

leaf echo-replies {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --echo-replies=false

--encoding

The --encoding parameter identifies the desired encoding format for RESTCONF request messages.

The supported values are xml and json.

leaf encoding {
  type ywt:encoding-type;
  default xml;
}

Syntax	enum (xml \| json)
Default:	xml
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --encoding=json

--entry-point

The --entry-point parameter identifies the RESTCONF entry point. Use this string instead of retrieving the XRD from the RESTCONF server to discover the entry point.

leaf entry-point {
  type string;
}

Syntax	string
Default:	`/restconf`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --entry-point=/api/restconf

--fill-optional

The --fill-optional parameter controls the default for the --optional parameter that can be passed to many interactive commands such as fill or create.

If 'true' then the user will be prompted to enter optional nodes while filling YANG datastore content.
If 'false' then the user will not be prompted to enter optional nodes while filling YANG datastore content.

leaf fill-optional {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	Yangcli-pro --fill-optional=true

--fixorder

The --fixorder parameter controls whether PDU parameters will be automatically sent in NETCONF PDUs in the correct order.

If 'true', the schema-defined, canonical order will be used.
If 'false', the specified order that parameters are entered will be used for the PDU order as well.

leaf fixorder {
  type boolean;
  default true;
}

Syntax	boolean (true or false)
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --fixorder=false

--force-target

The --force-target parameter controls whether the candidate or running configuration datastore will be used as the default edit target, when both are supported by the server.

candidate: Force the default edit target to be candidate.
running: Force the default edit target to be running.

leaf force-target {
  type enumeration {
    enum candidate {
    }
    enum running {
    }
  }
  default candidate;
}

Syntax	enum (candidate or running)
Default:	candidate
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --force-target=running

--handle-bad-reply

The --handle-bad-reply controls the behavior of the XML parser and dictates how a bad RPC reply will be handled, whether the bad node(s) will be pruned or the value will be adapted and the client will try to convert it to an acceptable type.

Settings that can be used:

adapt: Leaf or leaf-list: convert bad value to a string value and try to keep it if possible or prune if not. Container or list: leave in the data if possible or prune if not.
prune: Prune failing node(s).
error: Do not attempt to prune or modify nodes. Report an error.

leaf handle-bad-reply {
  type enumeration {
    enum adapt {
    }
    enum prune {
    }
    enum error {
    }
  }
  default error;
}

Syntax	enum (adapt \| prune \| error)
Default:	error
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --handle-bad-reply=prune

--help-width

The --help-width parameter specifies the line width to use when displaying help text for the help key '?' within config term mode.

This help mode aligns the description to the right of the widest object node name being displayed.

If the 'help' extension is used, then that text is displayed in its entirety. Otherwise the total line width will be limited to this help-width value.

Starting in the 23.10-6 release:

The help output is not limited to a single line.
Multiple lines will be output until the help-width total has been reached.
The screen dimensions will be used to determine the total width for a single line .
Blank lines and indentation in the description will be preserved in the help output.
This parameter is used to determine the total number of help characters to be displayed per object.
The value '0' indicates that the complete help text should be displayed for each object, instead of a specified limit.
The default value is '80' for backward compatibility.
The old limit of '511' has been extended to '65535'

Note

This parameter should be set to '0' to display full help text for each object.
Set to a large number such as '5000' to set a limit that is larger than almost all descriptions.

leaf help-width {
  type uint16 {
    range "0 | 80 .. max";
  }
  default 80;
}

Syntax	uint16
Default:	80
Recommend:	0
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --help-width=120

help-width Examples

The following examples show how the behavior of this parameter has changed.

--help-width=80 Prior to 23.10-6

admin# if:interfaces interface test <?>

  description                A textual description of the interface.
  enabled                    This leaf contains the configured, desired state...
  link-up-down-trap-enable   Controls whether linkUp/linkDown SNMP notificati...
  type                       The type of the interface.

--help-width=80 Starting in 23.10-6

admin# interfaces interface test

  description
    A textual description of the interface.

    A server implementation MAY map this leaf to the ifAlias
    MIB obje...

  enabled
    This leaf contains the configured, desired state of the
    interface.

    Systems that implement the IF-MIB use ...

  link-up-down-trap-enable
    Controls whether linkUp/linkDown SNMP notifications
    should be generated for this interface.

    If this no...

  type
    The type of the interface.

    When an interface entry is created, a server MAY
    initialize the type leaf with...

--help-width=0 Starting in 23.10-6

admin# if:interfaces interface test <?>

description
A textual description of the interface.

A server implementation MAY map this leaf to the ifAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and ifAlias. The definition of such a mechanism is outside the scope of this document.

Since ifAlias is defined to be stored in non-volatile storage, the MIB implementation MUST map ifAlias to the value of 'description' in the persistently stored configuration.

enabled
This leaf contains the configured, desired state of the interface.

Systems that implement the IF-MIB use the value of this leaf in the intended configuration to set IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry has been initialized, as described in RFC 2863.

Changes in this leaf in the intended configuration are reflected in ifAdminStatus.

link-up-down-trap-enable
Controls whether linkUp/linkDown SNMP notifications should be generated for this interface.

If this node is not configured, the value 'enabled' is operationally used by the server for interfaces that do not operate on top of any other interface (i.e., there are no 'lower-layer-if' entries), and 'disabled' otherwise.

type
The type of the interface.

When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface.

If a client tries to set the type of an interface to a value that can never be used by the system, e.g., if the type is not supported or if the type does not match the name of the interface, the server MUST reject the request. A NETCONF server MUST reply with an rpc-error with the error-tag 'invalid-value' in this case.

--hide-command

The --hide-command parameter specifies a top-level command that should be hidden from the tab key, help key and help command. Zero or more hide-command parameters can be used.

If the value does not contain a module name prefix, then the command will be disabled in all modules.

It will still be enabled but not visible to the user.
If a hidden command is used in a script or directly from the command line it will be accepted.
This parameter is ignored if the same command is also listed in a --disable-command parameter.

For example, to hide the NETCONF <delete-config> operation:

hide-command nc:delete-config

For example, to hide the internal 'else' command:

hide-command yc:else

--history-file

The --history-file parameter specifies the file location for the libtecla command line history file used if --autohistory is 'true'. This file will be created if if does not exist and the --autohistory parameter is 'true'.

leaf history-file {
  type string;
  default "~/.yumapro/.yangcli_pro_history";
}

Syntax	string
Default:	`~/.yumapro/.yangcli_pro_history`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --history-file=~/my-history.txt

--ignore-missing-vars

The --ignore-missing-vars parameter specifies how missing variable errors in data templates are handled. This parameter has no effect unless the --use-data-templates parameter is 'true'.

If 'true', then variable expressions that contain references to missing variables will not cause a parsing error. Instead, an empty string will be used or the value of a missing variable.
If 'false', then variable expressions that contain references to missing variables will cause a parsing error.

leaf ignore-missing-vars {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --ignore-missing-vars=true

--keepalive-interval

The --keepalive-interval parameter Specifies the time interval, in seconds, between keepalive messages sent from a session. This value is only used if --auto-keepalive is true.

Note

This parameter is NOT IMPLEMENTED. IT IS IGNORED.

leaf keepalive-interval {
  type uint32 {
    range "1 .. 3600";
  }
  units "seconds";
  default '4';
}

Syntax	uint32 (1 .. 3600)
Default:	4
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --keepalive-interval=10

--leaflist-multi-line

The --leaflist-multi-line parameter controls how a leaf-list can be edited in config-mode.

If 'true' then multiple leaf-lists can be configured at the same line.
If 'false' then only one leaf-list can be configured and it must be configured at the end of the line.

leaf leaflist-multi-line {
   type boolean;
   default false;
 }

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --leaflist-multi-line=true

--match-names-exec-mode

The --match-names-exec-mode parameter specifies how names are matched when performing UrlPath searches in Exec Mode parameters. Certain parameters for Commands that accept an XPath string as a parameter can be entered in different ways, using this CLI parameter.

Note

This parameter only affects XPath name matches, not command and parameter name matches.

The following values are supported:

Enum	Description
`exact`	The name must exactly match the node name for all characters in both name strings. This mode must be used in the server to be compliant with the NETCONF and RESTCONF protocols.
`exact-nocase`	The name must match the node name for all characters in both name strings. Strings are not case-sensitive.
`one`	The name must exactly match the first N characters of just one node name, which must be the only partial name match found.
`one-nocase`	The name must exactly match the first N characters of just one node name, which must be the only partial name match found. Strings are not case-sensitive.
`first`	The name must exactly match the first N characters of any node name. The first one found will be used.
`first-nocase`	The name must exactly match the first N characters of any node name. The first one found will be used. Strings are not case-sensitive.

Example Usage For :ref:`sget` Command

In this example, the setting one-nocase is used.
The string /NAC is used instead of the correct name /nacm

andy@localhost> sget /NAC

Filling container /nacm:
Roundtrip time: 0.006465 seconds

RPC Data Reply 4 for session 3 [default]:

rpc-reply {
  data {
    nacm {
      denied-operations 0
      denied-data-writes 0
      denied-notifications 0
      groups {
        group  G1 {
          name G1
        }
      }
    }
  }
}

leaf match-names-exec-mode {
  type ywt:NameMatchMode;
}

Syntax	enum: exact exact-nocase one one-nocase first first-nocase
Default:	exact
Min Allowed:	0
Max Allowed:	1
Introduced:	23.10-11
Supported by:	yangcli-pro yp-shell
Example:	yangcli-pro --match-names-exec-mode=one-nocase

--ncport

The --ncport parameter specifies the TCP port number that should be used for NETCONF sessions.

leaf ncport {
  type uint16 {
    range "1..max";
  }
  default 830;
}

Syntax	uint32
Default:	830
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --server=myserver --ncport=22 --user=fred --password=mypassword

--no-aliases

The --no-aliases parameter disables the alias substitution feature. The default is not present.

If present:

The alias file will not be read.
The aliases and alias commands will be disabled.

leaf no-aliases {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --no-aliases

--no-password

The --no-password parameter indicates that no user password is needed for the connection. It is used when connecting to a server in batch mode.

leaf no-password { type empty; }

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --no-password [server connect parms]

--optional

The --optional parameter specifies the default for the $$optional global variable.

If 'true' then the user will be prompted to enter optional nodes for all input.
If 'false' then the user will not be prompted to enter optional nodes for all input.

This parameter affects all YANG input and should normally not be used. The --fill-optional parameter should be used instead.

leaf optional {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --optional=true

--password

The --password parameter specifies the password string that should be used when a NETCONF session is connected during the startup of the program.

leaf password {
  type string;
  ncx:password;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --server=myserver --password=yangrocks --user=andy

--private-key

The --private-key parameter specifies the file path specification for the file containing the client-side private key.

If both 'public-key' and 'private-key' files are present, the client will attempt to connect to the server using these keys. If this fails, or not done, then password authentication will be attempted.

leaf private-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssh/id_rsa";
}

Syntax	string
Default:	`$HOME/.ssh/id_rsa`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --private-key=~/.ssh/mykey

--prompt

The --prompt parameter is used to set the command line prompt to the user defined value.

user1@homedev:~$ yp-shell  --prompt=admin@console

admin@console>

This parameter is only supported for yp-shell, not yangcli-pro.

The prompt can also be set using the $$prompt variable at any time. If this parameter is set then that value will be used as the prompt when yp-shell starts.

If this parameter is used, then --prompt-name and --prompt-type will be ignored.

leaf prompt {
   type string {
       length "1 .. 512";
   }
}

Syntax	string (length "1 .. 512")
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yp-shell
Example:	yp-shell --prompt=admin-session

--prompt-name

The --prompt-name parameter customize just the server name portion of the yp-shell prompt. It is ignored if --prompt is used.

This parameter is only supported for yp-shell, not yangcli-pro.

user1@homedev:~$ yp-shell  --prompt-name=myserver

user1@myserver>

leaf prompt-name {
   type string {
       length "1 .. 512";
   }
}

Syntax	string (length "1 .. 512")
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --prompt-name=yumaworks

--prompt-type

The --prompt-type parameter specifies the verbosity of the prompt storing.

The values allowed are brief, normal and full.

Note

This parameter is ignored by yangcli-pro and yp-shell. It has no effect on the prompt that is used.

leaf prompt-type {
  type ywt:show-mode;
  default normal;
}

Syntax	enum: brief normal full
Default:	normal
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --prompt-type=full

--public-key

The --public-key parameter specifies the file path specification for the file containing the client-side public key.

If both 'public-key' and 'private-key' files are present, the client will attempt to connect to the server using these keys. If this fails, or not done, then password authentication will be attempted.

leaf public-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssh/id_rsa.pub";
}

Syntax	string
Default:	`$HOME/.ssh/id_rsa.pub`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --public-key=~/.ssh/mykey.pub

--restrict-edit-mode

The --restrict-edit-mode parameter controls whether an 'restrict edit mode' will be supported for yp-shell.

This parameter can be used instead of specifying individual --disable-command parameters for all the editing commands.

If 'true' then the yp-shell editing commands will not be available to the user. Only config mode editing will be available.

The following commands will be disabled:
- create
- merge
- replace
- delete
- remove
- insert
- delete-all
- remove-all
- nvsave
Also, the following NETCONF operations will be disabled:

leaf restrict-edit-mode {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yp-shell
Example:	yp-shell --restrict-edit-mode=true

--run-command

The --run-command parameter specifies a command will be invoked upon startup.

In the yangcli-pro program, if the auto-connect parameters are provided, then a session will be established before running the command.

The --run-script parameter cannot be used if this parameter is used.

leaf run-command {
  type string {
    length "1 .. 4095";
  }
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --run-command="history load=~/test3-history"

--run-script

The --run-script parameter specifies a script will be invoked upon startup.

In the yangcli-pro program, if the auto-connect parameters are provided, then a session will be established before running the script.

If a quoted string is used, then any parameters after the script name will be passed to the script.

The --run-command parameter cannot be used if this parameter is used.

leaf run-script {
   type string {
     length "1 .. 4095";
   }
}

Syntax	string (file specification)
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --run-script="test3-start"

--save-session-vars

The --save-session-vars parameter specifies if session variables will be saved when the program exits. If use-session-vars is 'false' then this variable is ignored.

If 'true', then session variables will be saved when the program exits, but only if user variables are being saved.
If 'false', then session variables will not be saved when the program exits.

leaf save-session-vars {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --save-session-vars=false

--script-input

The --script-input parameter specifies whether scripts run in interactive mode should attempt to fill in missing command parameters from the CLI command line or not.

If true, then the user will be prompted for input when needed.
If false, then script commands will be attempted with whatever parameters are present in the script.

leaf script-input {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --script-input=false

--server-commands

The --server-commands parameter specifies whether RPC operations learned from server YANG modules will be added as a command available to the user.

The module ietf-netconf is exempt from this parameter.
Use the disable-command parameter to disable individual NETCONF operations.

leaf server-commands {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --server-commands=false

--shell-command

The --shell-command parameter specifies the shell program to invoke with the run-shell command, in case the default cannot be used.

leaf shell-command {
  type string;
  default "/bin/bash";
}

--shell-command parameter

Syntax	string
Default:	`/bin/bash`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro –shell-command=/bin/sh

--show-headers

The --show-headers parameter specifies the display mode for 'rpc-reply' message headers from a server.

If 'false' show the top-most data node if possible, when displaying server responses.
- The 'rpc-reply' container and 'data' container will not be shown in this case.
- Using this setting may cause regression tests to fail which match the entire text response.
- This is not done if there are multiple child nodes returned. A header is only removed if there is exactly one child node within it.
If 'true' the entire response message is shown. This is current behavior.

leaf show-headers {
  type boolean;
  default true;
}

Show Headers Example

Some example output from the sget-config source=running /nacm command is shown.

With --show-headers='true':

rpc-reply {
  data {
    nacm {
      groups {
        group  admin {
          name admin
          user-name admin1
          user-name admin2
        }
        group  guest {
          name guest
          user-name guest1
        }
      }
    }
  }
}

With --show-headers='false':

nacm {
  groups {
    group  admin {
      name admin
      user-name admin1
      user-name admin2
    }
    group  guest {
      name guest
      user-name guest1
    }
  }
}

--show-headers parameter

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Introduced:	24.10-2
Supported by:	yangcli-pro, yp-shell
Example:	yangcli-pro –show-headers=false

--ssl-certificate

The --ssl-certificate parameter contains the file path specification for the file containing the client-side SSL certificate.

If both 'certificate' and 'key' files are present, the client will attempt to setup a secure connection with the server using the certificate and SSL key.

If this fails, and the --ssl-fallback-ok parameter is set to 'true', the client will attempt to setup a raw TCP connection with the server.

leaf ssl-certificate {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/yangapi-client.crt";
}

Syntax	filespec
Default:	`$HOME/.ssl/yangapi-client.crt`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --ssl-certificate=~/certs/client.crt

--ssl-fallback-ok

The --ssl-fallback-ok parameter controls SSL connection behavior. This parameter only applies if the transport is 'ssl'.

If 'true' then an attempt to establish a plain TCP connection will be made if an SSL connection cannot be made.
If 'false' then an attempt to establish a plain TCP connection will not be made if an SSL connection cannot be made.

leaf ssl-fallback-ok {
    type boolean;
    default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --ssl-fallback-ok=false

--ssl-key

The --ssl-key parameter contains the file path specification for the file containing the client-side SSL key certificate.

If both 'certificate' and 'key' files are present, the client will attempt to setup a secure connection with the server using the certificate and SSL key.

If this fails, and the --ssl-fallback-ok leaf is set to 'true', the client will attempt to setup a raw TCP connection with the server.

leaf ssl-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/yangapi-client.key";
}

Syntax	filespec
Default:	`$HOME/.ssl/yangapi-client.key`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --ssl-key=~/certs/client.key

--ssl-trust-store

The --ssl-strust-store parameter contains the file path specification for the file containing the client-side ssl trust-store, or the path specification for the directory to use for finding trusted certificates.

If the default value is used and the file is not found, then the default directory location /etc/ssl/certs will be used.

leaf ssl-trust-store {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/trust-store.pem";
}

Syntax	filespec
Default:	`$HOME/.ssl/trust-store.pem` `/etc/ssl/certs` directory
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --ssl-trust-store= $HOME/certs/trust-store.pem

--term-length

The --term-length parameter specifies the length of the terminal to use for page mode output with the -More- prompt.

This parameter is ignored in batch mode.
It is only used if the output session is operating in interactive mode.
If the value 0 is used then the 'More' prompt will be disabled.
Otherwise this value represents the number of lines to output for each screen in pagination output mode.

leaf term-length {
  type uint16 {
    range "0 .. 511";
  }
  default 0;
}

Syntax	uint16 (0..511)
Default:	0
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --term-length=24

--test-suite-file

The --test-suite-file parameter contains the file specification of the default test suite configuration file to use.

leaf test-suite-file {
  type string;
  default "~/.yumapro/yangcli_pro_tests.conf";
}

Syntax	string:filespec
Default:	`$HOME/.yumapro/.yangcli_pro_tests.conf`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --test-suite-file=~/mytests.conf

--time-rpcs

The --time-rpcs parameter is used to measure the round-trip time of each <rpc> request and <rpc-reply> at the session level.

Echo the elapsed time value to screen if in interactive mode, as well as the log if the log is a file instead of stdout.
The $$time-rpcs system variable is derived from this parameter.

leaf time-rpcs {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --time-rpcs=true

--time-rpcs-stats

The --time-rpcs-stats parameter is used to control whether the timed rpc statistics should be saved if the time-rpcs parameter is set to 'true'.

If 'true', then timing statistics will be saved.
If 'false', then timing statistics will not be saved.
The $$time-rpcs-stats system variable is derived from this parameter.

leaf time-rpcs-stats {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --time-rpcs-stats=true

--time-rpcs-stats-file

The --time-rpc-stats-file parameter contains the file specification of the default rpc timing data file to use.

The default filename to use for saving RPC timing statistics. if the --time-rpcs and --time-rpcs-stats variables are true.

The $$time-rpcs-stats-file system variable is derived from this parameter.

leaf time-rpcs-stats-file {
  type string {
    length "1 .. max";
  }
  default "~/yangcli_pro_rpc_stats.txt";
}

Syntax	string:filespec
Default:	`$HOME/yangcli_pro_rpc_stats.txt`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --time-rpc-stats-file=~/mystats.txt

--timeout

The --timeout parameter specifies the number of seconds that should pass before giving up on a response during a NETCONF session.

The value zero means wait forever (no timeout).

typedef Timeout {
    type uint32;
    units seconds;
    default 30;
}

leaf timeout {
    type nt:Timeout;
}

Syntax	uint32 (0 for no timeout; otherwise number of seconds to wait)
Default:	30
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --timeout=0

--transport

The --transport parameter specifies the NETCONF transport protocol to use.

This parameter is also supported in the 'connect' command.

There are 5 values defined:

ssh
- standard NETCONF SSH transport (RFC 4742 or RFC 6242)
tcp
- tail-f NETCONF over TCP transport.
- Note that netconfd-pro does not support this transport protocol!
- The transport is TCP. The usage depends on the protocol used.
  - NETCONF over TCP: (tail-f NETCONF over TCP). If this enum is selected:
    - the default --ncport value is set to 2023
    - the --protocols value is set to netconf1.0
    - the --password value will be ignored
  - YANG-API or RESTCONF over HTTP/TCP. If this enum is selected:
    - the default --ncport value is set to 80
    - the --protocols value will not be changed
tcp-ncx
- YumaWorks NETCONF over TCP transport
- Note that netconfd-pro does support this transport protocol, if the netconfd-pro --socket-type CLI parameter is set to 'tcp'.
- If this enum is selected:
  - the default --ncport value is set to 2023
  - the --protocols value is set to netconf1.0 netconf1.1
  - the --password value will be ignored.
tls
- If the protocol is 'netconf' and this enum is selected, a NETCONF over TLS session will be attempted.
- If the protocol is 'RESTCONF' and this enum is selected the RESTCONF client will try to communicate with the server using the HTTPS protocol.
coap
- RESTCONF over CoAP. If this enum is selected:
  - the default --ncport value is set to 5683
  - the --password value will be ignored.
  - this parameter is no longer supported in yangcli-pro.

typedef transport-type {
  description
    "Identifies the transport protocol that should be used.";
  type enumeration {
    enum ssh {
    }
    enum tcp {
    }
    enum tcp-ncx {
    }
    enum tls {
      description
    }
    enum coap {
    }
  }
}

leaf transport {
    type ywt:transport-type;
    default ssh;
}

Syntax	Enum (ssh, tcp, tpc-ncx, tls, coap)
Default:	`ssh`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --transport=tls

--use-data-templates

The --use-data-templates parameter specifies if variable expressions are enabled for data in XML, JSON or .conf instance documents.

If 'true', then text matching the pattern for variable expressions in these instance documents will be processed as variable expressions.
If 'false', then text matching the pattern for variable expressions in these instance documents will be treated as plain strings.

leaf use-data-templates {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --use-data-templates=false

--use-rawxml

The --use-rawxml parameter specifies how file result variables will be read for XML files. Controls whether the XML will be parsed against the target YANG object (the default) or injected into a variable or request message from the raw XML text in the file.

If 'true', then inject the XML file into the request message
If 'false', then attempt to parse the XML file as the intended object. Fallback to 'true' if this parse fails.

Note

It is possible for yangcli-pro to change namespaces and drop XML attributes in some cases.
This parameter should be set to 'true' if an XML file is getting sent to the server incorrectly.
This parameter needs be set to 'true' if an XML file contains invalid XML or invalid YANG values (e.g. for negative testing)

leaf use-rawxml {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Recommend:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --use-rawxml=true

--use-session-vars

The --use-session-vars parameter specifies how global variables will be handled when set from the context of a named session.

If 'true', then an assignment (e.g., $$foo = 'bar') will only affect the session-specific instance of the variable, and only be visible within the scope of the named session.
If 'false', then assignment statements for global variables will affect the global instance of the variable, and be visible to all sessions.

If the current session is the default session, and not a named session, then the value of this variable is ignored, and all global variable assignments will affect the global instance of the variable, and be visible to all sessions.

leaf use-session-vars {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --use-session-vars=false

--use-traceid

The --use-traceid parameter controls whether the 'trace-id' attribute will be set in the RPC calls or not. By default, 'trace-id' attribute is disabled.

If 'true', then the XML RPC will contain 'trace-id' attribute
If 'false', then the XML RPC will not contain 'trace-id' attribute

leaf use-traceid {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --use-traceid=true

--use-xmlheader

The --use-xmlheader parameter specifies how file result variables will be written for XML files.

Controls whether the XML preamble header will be written or not. Do not set to 'false' or XML messages sent to a server will be invalid.

leaf use-xmlheader {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --use-xmlheader=false

--user

The --user parameter specifies the user name string on the NETCONF server that should be used when establishing a NETCONF session.

leaf user {
  type nt:NcxName;
}

Syntax	string:user name
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --user=admin --server=myserver

--uservars-file

The --uservars-file parameter contains the file specification of the user global variables XML file to use.

leaf uservars-file {
  type string;
  default "~/.yumapro/yangcli_pro_uservars.xml";
}

Syntax	string:filespec
Default:	`$HOME/.yumapro/yangcli_pro_uservars.xml`
Min Allowed:	0
Max Allowed:	1
Supported by:	yangcli-pro
Example:	yangcli-pro --uservars-file=~/myvars.xml

--with-enable-mode

The --with-enable-mode parameter controls whether an 'enable mode' will be supported for yp-shell.

If set to 'true', the user must enter the enable command to enter enable mode. If the enable password has been configured then this password must be provided by the user in order to enter enable mode.

Within enable mode, the 'config term' command can be used to enter configuration mode.
If set to 'false', then enable mode will not be used and the enable, enable password, and enable no-password commands will not be present.

leaf with-enable-mode {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yp-shell
Example:	yp-shell --with-enable-mode=true

--with-notif-commands

The --with-notif-commands parameter controls whether notifications will be supported for yp-shell.

If ‘true’ then yp-shell will include the create-subscription and cancel-subscription commands.
If ‘false’ then yp-shell will not include the create-subscription and cancel-subscription commands.

This parameter does not affect yp-shell echoing of notification messages. The --echo-notifs and --echo-notif-loglevel parameters need to be set appropriately to echo received notification messages.

leaf with-notif-commands {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yp-shell
Example:	yp-shell --with-notif-commands=true

--yangmap

The --yangmap parameter specifies a yangmap XML file that should be loaded into the program. See yumaworks-yangmap.yang for details on using YANG mappings in config term mode.

leaf-list yangmap {
  type string;   // filespec
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	yangcli-pro
Example:	yangcli-pro --yangmap=$HOME/maps/map1.xml

--ypshell-exec-ok

The --ypshell-exec-ok parameter specifies if the yp-shell program can have access to the exec type of commands such as the run and run-shell commands. Only applies to yp-shell.

If 'true' then yp-shell will allow the user session to use the following commands:

If 'false' then these commands will not be enabled in the yp-shell program.

This parameter cannot be changed at run-time with a system variable.

The --allow-shell parameter must also be set to 'true' for the run-shell command to be enabled.

leaf ypshell-exec-ok {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yp-shell
Example:	yp-shell --ypshell-exec-ok=true

--zmqapi-gateway-id

The --zmqapi-gateway-id parameter specifies the identifier string for the yangcli-gw process to use in ZMQAPI Protocol messages and logging output.

leaf zmqapi-gateway-id {
   type nt:NcxName;
   default "gateway1";
}

Syntax	string
Default:	`gateway1`
Min Allowed:	0
Max Allowed:	1
Introduced:	23.10T-0
Supported by:	yangcli-gw
Example:	yangcli-gw --zmqapi-gateway-id=gw-app5

--zmqapi-publisher-endpoint

The --zmqapi-publisher-endpoint parameter specifies the URI string for the yangcli-gw process to use to as the ZeroMQ endpoint for the ZMQAPI Event Channel.

This is the ZeroMQ endpoint URI that the yangcli-gw will use to publish ZMQAPI notifications.
A client is expected to connect to this endpoint using the 'ZMQ_SUB' socket type.
The client is expected to listen only on this socket.
Then yangcli-gw will send ZMQAPI.1 PUB messages as needed on this socket.

leaf zmqapi-publisher-endpoint {
  type string;  // URI for zeroMQ endpoint
  default "tcp://127.0.0.1:5556";
}

Syntax	string
Default:	`tcp://127.0.0.1:5556`
Min Allowed:	0
Max Allowed:	1
Introduced:	23.10T-0
Supported by:	yangcli-gw
Example:	yangcli-gw --zmqapi-responder-endpoint="tcp://*:9998"

--zmqapi-responder-endpoint

The --zmqapi-responder-endpoint parameter specifies the URI string for the yangcli-gw process to use to as the ZeroMQ endpoint for the ZMQAPI Command Channel.

This is the ZeroMQ endpoint URI that the yangcli-gw will use to listen for ZMQAPI commands.
A client is expected to connect to this endpoint using the 'ZMQ_REQ' socket type.
The client can send ZMQAPI.1 REQ messages on this socket.
Then yangcli-gw will respond with a ZMQAPI.1 REP message on this socket.

leaf zmqapi-responder-endpoint {
  type string;  // URI for zeroMQ endpoint
  default "tcp://127.0.0.1:5555";
}

Syntax	string
Default:	`tcp://127.0.0.1:5555`
Min Allowed:	0
Max Allowed:	1
Introduced:	23.10T-0
Supported by:	yangcli-gw
Example:	yangcli-gw --zmqapi-publisher-endpoint="tcp://*:9999"