Radek Krejci | ed5acc5 | 2019-04-25 15:57:04 +0200 | [diff] [blame] | 1 | .\" Manpage for yanglint. |
| 2 | .\" Process this file with |
| 3 | .\" groff -man -Tascii yanglint.1 |
| 4 | .\" |
| 5 | |
| 6 | .TH YANGLINT 1 "2016-10-27" "libyang" |
| 7 | .SH NAME |
| 8 | yanglint \- YANG lint tool |
| 9 | . |
| 10 | .SH SYNOPSIS |
| 11 | .B yanglint |
| 12 | .br |
| 13 | .B yanglint |
| 14 | [\fIOPTIONS\fP] |
| 15 | [\-f { \fByang\fP | \fByin\fP | \fBtree\fP } ] |
| 16 | .I FILE ... |
| 17 | .br |
| 18 | .B yanglint |
| 19 | [\fIOPTIONS\fP] |
| 20 | [\-f { \fBxml\fP | \fBjson\fP } ] |
| 21 | \fISCHEMA\fP... |
| 22 | \fIFILE\fP... |
| 23 | . |
| 24 | .SH DESCRIPTION |
| 25 | \fByanglint\fP is a command-line tool for validating and converting YANG |
| 26 | schemas and the YANG modeled data. For a simple use, it validates the provided |
| 27 | file and if the output format specified, it converts input data into the output |
| 28 | format. If started with no argument, \fByanglint\fP opens interactive |
| 29 | environment where the user is allowed to work with schemas and data in a more |
| 30 | complex way. |
| 31 | . |
| 32 | .SH OPTIONS |
| 33 | .TP |
| 34 | .BR "\-h\fR,\fP \-\^\-help" |
| 35 | Outputs usage help and exits. |
| 36 | .TP |
| 37 | .BR "\-v\fR,\fP \-\^\-version" |
| 38 | Outputs the version number and exits. |
| 39 | .TP |
| 40 | .BR "\-V\fR,\fP \-\^\-verbose" |
| 41 | Increases the verbosity level. If not specified, only errors are printed, with |
| 42 | each appearance it adds: warnings, verbose messages, debug messages (if compiled |
| 43 | with debug information). |
| 44 | .TP |
| 45 | .BR "\-p \fIPATH\fP\fR,\fP \-\^\-path=\fIPATH\fP" |
| 46 | Specifies search path for getting imported modules or included submodules. The option |
| 47 | can be used multiple times. The current working directory and path of the module |
| 48 | being added is used implicitly. |
| 49 | .TP |
| 50 | .BR "\-s\fR,\fP \-\^\-strict" |
| 51 | Changes handling of unknown data nodes - instead of silently ignoring unknown data, |
| 52 | error is printed and data parsing fails. This option applies only on data parsing. |
| 53 | .TP |
| 54 | .BR "\-f \fIFORMAT\fP\fR,\fP \-\^\-format=\fIFORMAT\fP" |
| 55 | Converts the content of the input \fIFILE\fPs into the specified \fIFORMAT\fP. If no |
| 56 | \fIOUTFILE\fP is specified, the data are printed on the standard output. Only the |
| 57 | compatible formats for the input \fIFILE\fPs are allowed, see the section \fBFORMATS\fP. |
| 58 | .TP |
| 59 | .BR "\-o \fIOUTFILE\fP\fR,\fP \-\^\-output=\fIOUTFILE\fP" |
| 60 | Writes the output data into the specified \fIOUTFILE\fP. The option can be used |
| 61 | only in combination with \fB--format\fR option. In case of converting schema, only |
| 62 | a single input schema \fIFILE\fP is allowed. In case of data input \fIFILE\fPs, |
| 63 | input is merged and printed into a single \fIOUTFILE\fP. |
| 64 | .TP |
| 65 | .BR "\-F \fIFEATURES\fP\fR,\fP \-\^\-features=\fIFEATURES\fP" |
| 66 | Specifies the list of enabled features in the format |
| 67 | \fIMODULE\fP:[\fIFEATURE\fP,...]. In case of processing multiple modules, the |
| 68 | option can be used repeatedly. To disable all the features, use an empty list |
| 69 | specified for the particular module. |
| 70 | .TP |
| 71 | .BR "\-d \fIMODE\fP\fR,\fP \-\^\-default=\fIMODE\fP" |
| 72 | Print data with default values, according to the \fIMODE\fP (to print attributes, |
| 73 | the ietf-netconf-with-defaults model must be loaded). The \fIMODE\fP is one of the following: |
| 74 | \[bu] \fBall\fP - add missing default nodes |
| 75 | \[bu] \fBall-tagged\fP - add missing default nodes and mark all the default nodes with the attribute |
| 76 | \[bu] \fBtrim\fP - remove all nodes with a default value |
| 77 | \[bu] \fBimplicit-tagged\fP - add missing nodes and mark them with the attribute |
| 78 | .TP |
| 79 | .BR "\-t \fITYPE\fP\fR,\fP \-\^\-type=\fITYPE\fP" |
| 80 | Specify data tree type in the input data \fIFILE\fPs. The \fITYPE\fP is one of the following: |
| 81 | \[bu] \fBauto\fP - Resolve data type (one of the following) automatically (as pyang does). Applicable only on XML input data. |
| 82 | \[bu] \fBdata\fP - Complete datastore with status data (default type). |
| 83 | \[bu] \fBconfig\fP - Configuration datastore (without status data). |
| 84 | \[bu] \fBget\fP - Result of the NETCONF <get> operation. |
| 85 | \[bu] \fBgetconfig\fP - Result of the NETCONF <get-config> operation. |
| 86 | \[bu] \fBedit\fP - Content of the NETCONF <edit-config> operation. |
| 87 | \[bu] \fBrpc\fP - Content of the NETCONF <rpc> message, defined as YANG's rpc input statement. |
| 88 | \[bu] \fBrpcreply\fP - Reply to the RPC. This is just a virtual \fITYPE\fP, for parsing replies, '\fBauto\fP' must be used since the data \fIFILE\fPs are expected in pairs. |
| 89 | .br |
| 90 | The first input data \fIFILE\fP is expected as '\fBrpc\fP' \fITYPE\fP, the second \fIFILE\fP is expected as reply to the previous RPC. |
| 91 | \[bu] \fBnotif\fP - Notification instance (content of the <notification> element without <eventTime>. |
| 92 | .TP |
| 93 | .BR "\-O \fIFILE\fP\fR,\fP \-\^\-operational=\fIFILE\fP] |
| 94 | Optional parameter for '\fBrpc\fP' and '\fBnotif\fP' \fITYPE\fPs, the \fIFILE\fP contains running configuration datastore and |
| 95 | state data referenced from the RPC/Notification. The same data apply to all input data \fIFILE\fPs. Note that the file |
| 96 | is validated as '\fBdata\fP' \fITYPE\fP. Special value '\fB!\fP' can be used as \fIFILE\fP argument to ignore the external references. |
| 97 | .TP |
| 98 | .BR "\-y \fIYANGLIB_PATH\fP" |
| 99 | Specify path to a yang-library data file (XML or JSON) describing the initial context. |
| 100 | If provided, yanglint loads the modules according to the content of the yang-library data tree. |
| 101 | Otherwise, an empty content with only the internal libyang modules is used. This does |
| 102 | not limit user to load another modules explicitly specified as command line parameters. |
| 103 | . |
| 104 | .SH FORMATS |
| 105 | There are two types of formats to use. |
| 106 | .TP |
| 107 | .I Schemas |
| 108 | In case of schemas, the content can be converted into the '\fByang\fP', '\fByin\fP' |
| 109 | and '\fBtree\fP' formats. As input, only YANG and YIN files are |
| 110 | accepted. Note, that the corresponding file extension is required. |
| 111 | .TP |
| 112 | .I Data\ \ \ |
| 113 | In case of YANG modeled data, the content can be converted between '\fBxml\fP' |
| 114 | and '\fBjson\fP' formats. Remember that the corresponding file extension of the |
| 115 | input file is required. |
| 116 | . |
| 117 | |
| 118 | .SH EXAMPLES |
| 119 | .IP \[bu] 2 |
| 120 | Open interactive environment: |
| 121 | yanglint |
| 122 | .IP \[bu] |
| 123 | Convert YANG model into YIN and print it to the stdout: |
| 124 | yanglint --format=yin ./ietf-system.yang |
| 125 | .IP \[bu] |
| 126 | Convert ietf-system configuration data from XML to JSON: |
| 127 | yanglint --format=json --type=config --output=data.json ./ietf-system.yang ./data.xml |
| 128 | |
| 129 | .SH SEE ALSO |
| 130 | https://github.com/CESNET/libyang (libyang homepage and Git repository) |
| 131 | . |
| 132 | .SH AUTHORS |
| 133 | Radek Krejci <rkrejci@cesnet.cz>, Michal Vasko <mvasko@cesnet.cz> |
| 134 | . |
| 135 | .SH COPYRIGHT |
| 136 | Copyright \(co 2015-2017 CESNET, a.l.e. |