YANGLINT(1)

📦
version 6.1.4 · 2 versions
, in ubuntu stonking

💖 YANGLINT(1) — the yanglint era 💖

okay bestie, settle in, because this is a General Commands Manual page for yanglint, aka the YANG lint tool, and she is that girl. section 1, manual page realness. 🎀

✨ NAME ✨

yanglint — YANG lint tool 🦋

🌸 SYNOPSIS 🌸

yanglint
yanglint [OPTIONS] [-f { yang | yin | tree } ] FILE ...
yanglint [OPTIONS] [-f { xml | json } ] SCHEMA...  FILE...

like. three whole moods. pick your fighter. 💅

💜 DESCRIPTION 💜

so yanglint is a command-line tool for validating and converting YANG schemas and the YANG modeled data. no cap.

for a simple use, it validates the provided file, and if the output format is specified, it converts input data into the output format. ✨

and if you start it with no argument at all? it opens the interactive environment where you — yes you, main character — are allowed to work with schemas and data in a more complex way. 👑

🎀 OPTIONS 🎀

  • -h, --help — show this help message and then dip. exit. bye. 👋
  • -v, --version — show the version number and exit. it's giving quick flex. ⭐
  • -V, --verbose — crank up libyang verbosity and show verbose messages. specify it a second time and you get the even-more debug messages. 🐛
  • -Q, --quiet — turn libyang verbosity down and hide warnings. specify it a second time and errors get hidden too, so literally no libyang messages are printed at all. 🤫
  • -f FORMAT, --format=FORMAT — convert input into FORMAT. supported formats: yang, yin, tree, info and feature-param for schemas; xml, json, and lyb for data. pick one, slay. 🔥
  • -I FORMAT, --in-format=FORMAT — load the data in one of: xml, json, lyb. if you don't specify the input format, it's detected from the file extension. psychic behavior, honestly. 🔮
  • -p PATH, --path=PATH — search path for schema (YANG/YIN) modules. can be used multiple times. the current working directory and the path of the module being added are used implicitly. subdirectories are also searched. she's thorough. 💅
  • -D, --siable-searchdir — do not implicitly search in current working directory for schema modules. if specified a second time, don't even search in the module directory (all modules must be explicitly specified). (yes, that spelling is the real flag name bestie, we don't fix it, we respect it 💀)
  • -F FEATURES, --features=FEATURES — specific module features to support, in the form <module-name>:(<feature>,)*. use <feature> '*' to enable all features of a module. this option can be specified multiple times to enable features in multiple modules. if this option is not specified, all the features in all the implemented modules are enabled. 🧚
  • -i, --make-implemented — make the imported modules referenced from any loaded module also implemented. if specified a second time, all the modules are set implemented. 😤
  • -P PATH, --schema-node=PATH — print only the specified subtree of the schema. the PATH is the XPath subset mentioned in documentation as the Path format. can be combined with the --single-node option to print information only about the specified node. 🎯
  • -q, --single-node — the supplement to the --schema-node option, to print information only about a single node specified as the PATH argument. one node. just the one. 🙈
  • -s SUBMODULE, --submodule=SUBMODULE — print the specific submodule instead of the main module. 🦋
  • -x FILE, --ext-data=FILE — file containing the specific data required by an extension. required by the schema-mount extension, for example, when the operational data are expected in the file. file format is guessed. ✨
  • -n, --not-strict — do not require strict data parsing (silently skip unknown data). has no effect for schemas. 🫶
  • -e, --present — validate only with the schema modules whose data actually exist in the provided input data files. takes effect only with the 'data' or 'config' TYPEs. used to avoid requiring mandatory nodes from modules which data are not present in the provided input data files. lowkey genius. 💡
  • -t TYPE, --type=TYPE — specify the data tree type in the input data FILEs. the TYPE is one of the following:
    • data — complete (operational) datastore with state data (default). 👑
    • config — configuration datastore (without state data).
    • get — result of the NETCONF <get> operation.
    • getconfig — result of the NETCONF <get-config> operation.
    • edit — content of the NETCONF <edit-config> operation.
    • rpc — content of the NETCONF <rpc> message, defined as YANG's rpc input statement.
    • nc-rpc — similar to 'rpc' but expect and check also the NETCONF envelopes <rpc> or <action>.
    • reply — reply to the RPC/Action. note that the reply data are expected inside a container representing the original RPC/Action. this is necessary to identify appropriate data definitions in the schema module. 📦
    • nc-reply — similar to 'reply' but expect and check also the NETCONF envelope <rpc-reply> with output data nodes as direct descendants. the original RPC/action invocation is expected in a separate parameter '-R' and is parsed as 'nc-rpc'.
    • notif — notification instance (content of the <notification> element without <eventTime>).
    • nc-notif — similar to 'notif' but expect and check also the NETCONF envelope <notification> with element <eventTime> and its sibling as the actual notification. 🔔
    • ext — validates extension data based on loaded YANG modules. needs to be used with the -k parameter.
  • -d MODE, --default=MODE — print data with default values, according to the MODE (to print attributes, the ietf-netconf-with-defaults model must be loaded):
    • all — add missing default nodes.
    • all-tagged — add missing default nodes and mark all the default nodes with the attribute. 🏷️
    • trim — remove all nodes with a default value. ✂️
    • implicit-tagged — add missing nodes and mark them with an attribute.
  • -E XPATH, --data-xpath=XPATH — evaluate the XPATH expression over the data and print the nodes satisfying the expression. the output format is specific, and the option cannot be combined with the -f and -d options. also, all the data inputs are merged into a single data tree where the expression is evaluated, so the -m option is always set implicitly. 😮
  • -l, --list — print info about the loaded schemas. (i — imported module, I — implemented module). in case the '-f' option with data encoding is specified, the list is printed as 'ietf-yang-library' data. 📋
  • -L LINE_LENGTH, --tree-line-length=TREE_LENGTH — the limit of the maximum line length on which the 'tree' format will try to be printed. 📏
  • -o OUTFILE, --output=OUTFILE — write the output to OUTFILE instead of stdout. 🫶
  • -O FILE, --operational=FILE — provide optional data to extend validation of the '(nc-)rpc', '(nc-)reply' or '(nc-)notif' TYPEs. the FILE is supposed to contain the operational datastore referenced from the operation. in case of a nested notification or action, its parent existence is also checked in these operational data. 🗂️
  • -R FILE, --reply-rpc=FILE — provide source RPC for parsing of the 'nc-reply' TYPE. the FILE is supposed to contain the source 'nc-rpc' operation of the reply. 💌
  • -m, --merge — merge input data files into a single tree and validate at once. has effect only for the 'data' and 'config' TYPEs. 🌈
  • -y, --yang-library — load and implement the internal 'ietf-yang-library' YANG module. note that this module includes definitions of mandatory state data that can result in unexpected data validation errors. ⚠️
  • -Y FILE, --yang-library-file=FILE — parse FILE with 'ietf-yang-library' data and use them to create an exact YANG schema context. if specified, the '-F' parameter (enabled features) is ignored. 🙅
  • -X, --extended-leafref — allow usage of the deref() XPath function within leafref. 🔗
  • -J, --json-null — allow usage of JSON empty values ('null') within input data. 🕳️
  • -k, --ext-inst — name of extension instance in format: <module-name>:<extension-name>:<argument>. needs to be used with the -t ext parameter. 🔧
  • -G GROUPS, --debug=GROUPS — enable printing of a specific debugging message group (nothing will be printed unless verbosity is set to debug): <group>[,<group>]* (dict, xpath, dep-sets). 🐞

🦋 FORMATS 🦋

there are two types of formats to use. two!! ✌️

Schemas

in case of schemas, the content can be converted into the 'yang', 'yin' and 'tree' formats. as input, only YANG and YIN files are accepted. note that the corresponding file extension is required. 📎

Data

in case of YANG modeled data, the content can be converted between 'xml' and 'json' formats. remember that the corresponding file extension of the input file is required. 📎

⭐ EXAMPLES ⭐

  1. open the interactive environment:
yanglint
  1. convert a YANG model into YIN and print it to the stdout:
yanglint --format=yin ./ietf-system.yang
  1. convert ietf-system configuration data from XML to JSON:
yanglint --format=json --type=config --output=data.json ./ietf-system.yang ./data.xml

ate. no crumbs. 💅

👑 SEE ALSO 👑

💖 AUTHORS 💖

Radek Krejci <rkrejci@cesnet.cz>, Michal Vasko <mvasko@cesnet.cz> 🫶

Copyright © 2015 - 2025 CESNET, a.l.e.

ok that's the whole page bestie, every single flag accounted for, nothing skipped, we ate and left no crumbs 🍓

published by libyang, dated 2025-8-19, and that's the vibe check, periodt. ✨💜

📦 where this page comes from