Thank you for the guidance.
I remember now, why I started to pass in my own "-" for empty fields.
When I pass certain variable values through to a main.zeek script event handler, I
error messages from the scripting layer (i.e. "...value used but not set").
If I pass an empty string (i.e. a C string with a '\0' in the first array
position), I see the "value used but not set" warning.
Also, for some reason, I'm now seeing the same error, when I pass a 0 value to my
"serial_low" event parameter.
(The serial_low is of type "Count" in the event handler)
(Also, serial_low is the last parameter to the event handler)
I've attached the stdOut and stdErr output from my zeek cmd execution.
From: Jon Siwek <jsiwek(a)corelight.com>
Sent: Monday, May 3, 2021 6:02 PM
To: Brett D. Rasmussen <brett.rasmussen(a)inl.gov>
Cc: zeek(a)lists.zeek.org <zeek(a)lists.zeek.org>
Subject: Re: [EXTERNAL] Re: [Zeek] Untraceable zeekygen "warning:" messages
On Mon, May 3, 2021 at 4:31 PM Brett D. Rasmussen
When I try to print a string that contains only one
character (i.e. "-"), Zeek outputs the following to the associated log: \x2d
If I output the string ".", it prints as . in the log file.
Is there a way to persuade Zeek to output a single "-" character in a column of
By default, a dash ('-') in log files signifies absence of a value
(e.g. for &optional record fields), so to avoid ambiguity with '-' in
other contexts (e.g. a string with a value of "-"), those others get
escaped as \x2d.
You could change the default character used for absent values via a
'redef' of `LogAscii::unset_field` to something else:
There is also a `LogAscii::empty_field` option to control what an
empty value looks like in the log:
An empty-string would render as "(empty)" in logs by default, so maybe
you want to stick with that in your scripts instead of trying to use a
dash ('-') since that already conflicts with the default value of
unset fields. Or you could pick a different sentinel value than '-'
to use in place of empty-strings in your particular script.
Also, if you were to change either setting, note that escaping will
still happen for any logged-value found to conflict with the new