zeekygen/example.zeek
- ZeekygenExample
This is an example script that demonstrates Zeekygen-style documentation. It generally will make most sense when viewing the script’s raw source code and comparing to the HTML-rendered version.
Comments in the from ##!
are meant to summarize the script’s
purpose. They are transferred directly into the generated
reStructuredText
(reST) document associated with the script.
Tip
You can embed directives and roles within ##
-stylized comments.
There’s also a custom role to reference any identifier node in the Zeek Sphinx domain that’s good for “see alsos”, e.g.
See also: ZeekygenExample::a_var
,
ZeekygenExample::ONE
, SSH::Info
And a custom directive does the equivalent references:
See also: ZeekygenExample::a_var
, ZeekygenExample::ONE
, SSH::Info
- Namespace:
ZeekygenExample
- Imports:
base/frameworks/notice, base/protocols/http, policy/frameworks/software/vulnerable.zeek
Summary
Redefinable Options
Add documentation for “an_option” here. |
|
Default initialization will be generated automatically. |
State Variables
Put some documentation for “a_var” here. |
|
The first sentence for a particular identifier’s summary text ends here. |
|
Types are inferred, that information is self-documenting. |
Types
General documentation for a type “ComplexRecord” goes here. |
|
An example record to be used with a logging stream. |
|
Documentation for the “SimpleEnum” type goes here. |
|
General documentation for a type “SimpleRecord” goes here. |
Redefinitions
|
|
Document the “SimpleEnum” redef here with any special info regarding the redef itself.
|
|
Document the record extension redef itself here.
|
Events
Summarize “an_event” here. |
Functions
Summarize purpose of “a_function” here. |
Detailed Interface
Redefinable Options
- ZeekygenExample::an_option
-
Add documentation for “an_option” here. The type/attribute information is all generated automatically.
- ZeekygenExample::option_with_init
-
Default initialization will be generated automatically. More docs can be added here.
State Variables
- ZeekygenExample::a_var
- Type:
Put some documentation for “a_var” here. Any global/non-const that isn’t a function/event/hook is classified as a “state variable” in the generated docs.
- ZeekygenExample::summary_test
- Type:
The first sentence for a particular identifier’s summary text ends here. And this second sentence doesn’t show in the short description provided by the table of all identifiers declared by this script.
- ZeekygenExample::var_without_explicit_type
- Type:
- Default:
"this works"
Types are inferred, that information is self-documenting.
Types
- ZeekygenExample::ComplexRecord
- Type:
- Attributes:
General documentation for a type “ComplexRecord” goes here.
- ZeekygenExample::Info
-
An example record to be used with a logging stream. Nothing special about it. If another script redefs this type to add fields, the generated documentation will show all original fields plus the extensions and the scripts which contributed to it (provided they are also @load’ed).
- ZeekygenExample::SimpleEnum
- Type:
-
- ZeekygenExample::ONE
Documentation for particular enum values is added like this. And can also span multiple lines.
- ZeekygenExample::TWO
Or this style is valid to document the preceding enum value.
- ZeekygenExample::THREE
- ZeekygenExample::FOUR
And some documentation for “FOUR”.
- ZeekygenExample::FIVE
Also “FIVE”.
Documentation for the “SimpleEnum” type goes here. It can span multiple lines.
- ZeekygenExample::SimpleRecord
- Type:
General documentation for a type “SimpleRecord” goes here. The way fields can be documented is similar to what’s already seen for enums.
Events
- ZeekygenExample::an_event
-
Summarize “an_event” here. Give more details about “an_event” here.
ZeekygenExample::a_function should not be confused as a parameter in the generated docs, but it also doesn’t generate a cross-reference link. Use the see role instead:
ZeekygenExample::a_function
.- Parameters:
name – Describe the argument here.
Functions
- ZeekygenExample::a_function
-
Summarize purpose of “a_function” here. Give more details about “a_function” here. Separating the documentation of the params/return values with empty comments is optional, but improves readability of script.
- Parameters:
tag – Function arguments can be described like this.
msg – Another param.
- Returns:
Describe the return type here.