New Prompt

From the beginning, lnav used the readline library for handling the command prompt at the bottom of the screen. It worked. But that solution had many limitations: simplistic tab-completion; complicated integration, which used a separate process; glitchy syntax highlighting; lack of multi-line support.

To address these limitations, I’ve written a custom text input widget. The new widget should maintain almost all of the existing functionality of readline (except for the readline configuration file) while also improving the overall experience.

The following sub-sections highlight some of the new functionality.

History

History search can be activated with CTRL-R and is a fuzzy search now. The history is also kept in a SQLite DB so that it is saved immediately and available across sessions. The status of the executed command is also saved and shown in the history so it is easy to see what worked or did not.

Search Suggestions

Searching for a phrase is now easier because lnav will automatically suggest the next word from the display. For example, when searching for “release the kraken”, typing “release” followed by a space will suggest “the”. Pressing TAB will then complete “the” and then pressing SPACE will suggest “kraken”.

Comment Command

The :comment command, if you aren’t already familiar, allows you to attach a textual comment to a log message. The comment will show up below the log message and can be styled using Markdown syntax.

Writing a comment in a single line as afforded by readline was pretty cumbersome. If you wanted to add a new line, you had to insert a \n.

Now, with the new implementation, when you enter :comment , the prompt will immediately switch to multi-line mode. Markdown syntax is now highlighted and the rendered version will be shown in the preview panel. To make comments even more useful, you can add links to messages using permalinks (see below). Clicking the link in the comment will jump the view to the targeted message.

Code blocks with the language set to lnav will display a “play” button next to commands that you can click on to execute the command. This can be useful for saving commands/queries that were useful when you were debugging something.

DB Statements

The other functionality that benefits greatly from a multi-line prompt is entering DB statements. The SQL prompt starts in single-line mode, but can easily be switched to multi-line by pressing CTRL-L. The switch to multi-line will also reformat the SQL/PRQL statement to split it over multiple lines.

Cut to the System Clipboard

Cutting text in the prompt using the keyboard shortcuts now copies the text to the system clipboard.

Saving the Prompt Contents

If you want to export the prompt contents to edit in another editor or for some other reason, you can press CTRL-O to save to a file named saved-prompt.lnav. The file is saved in the lnav formats/installed directory so that it can be executed using |saved-prompt. Also, if VS Code is available, it will be called to edit the file since there is an lnav extension available. A different editor can be used by changing the /tuning/external-editor configuration.

Mouse Support

Finally, the prompt has support for mouse input. Left-click will position the cursor. Click-drag to select a range of text. A right-click will copy the selection to the system clipboard.

Time Column

The “time column” feature displays an abbreviated timestamp and log level in a column on the left when enabled, while also hiding the original timestamp and level. The column reduces the size of log messages and aligns timestamps/log-levels across log formats to make for easier reading. Enabling the column is done simply by scrolling to the right. Scrolling left will disable the column and display the full log message as usual.

This feature is gated by the /ui/views/log/time-column setting, with the following values:

• disabled: scrolling right works as normal and does not insert the time column.
• enabled: scrolling right enables the time column.
• default: the time column is enabled and the default on startup.

Empty View Messages

If no files are loaded into the LOG or TEXT views, a message will be displayed to give you a hint to use the :open command or switch the view.

Control Characters in Table Cells

In the DB view, table cells will now display non-printable characters as their unicode symbols and highlighted in yellow.

Permalinks for Log Messages

Log messages now have permalinks that can be used to reference them from other locations. The permalink for a message is shown in the parser details overlay (activated by pressing p). Selecting the “Permalink:” line in the overlay and then pressing c will copy the link to your clipboard. The link is also available in the log_line_link column of the log tables. These permalinks can be used with the :goto command to move to the log message.

“Measure” Collation Function

A measure_with_units SQLite collation function has been added that can compare numbers with unit suffixes, like “10KB” or “1.2ms”. The :create-search-table command will also use this collation function for capture patterns that are likely to capture a number with a unit. Associating the correct collation function means that sorting will work correctly. For example, “1KB” will be greater than “5B”.

You can execute a PRQL query using the existing database prompt (press ;). A query is interpreted as PRQL if it starts with the from keyword. After from, the database table should be provided. The table for the focused log message will be suggested by default. You can accept the suggestion by pressing TAB. To add a new stage to the pipeline, enter a pipe symbol (|), followed by a PRQL transform and its arguments. In addition to the standard set of transforms, lnav provides some convenience transforms in the stats and utils namespaces. For example, stats.count_by can be passed one or more column names to group by and count, with the result sorted by most to least.

As you enter a query, lnav will update various panels on the display to show help, preview data, and errors. The following is a screenshot of lnav viewing a web access log with a query in progress:

The top half is the usual log message view. Below that is the online help panel showing the documentation for the stats.count_by PRQL function. lnav will show the help for what is currently under the cursor. The next panel shows the preview data for the pipeline stage that precedes the stage where the cursor is. In this case, the results of from access_log, which is the contents of the access log table. The second preview window shows the result of the pipeline stage where the cursor is located.

There is still a lot of work to be done on the integration and PRQL itself, but I’m very hopeful this will work out well in the long term. Many thanks to the PRQL team for starting the project and keeping it going, it’s not easy competing with SQL.

(Since I’m not well-versed in forensic work, I followed this great walkthrough.)

Q1: Which service did the attackers use to gain access to the system?

We can probably figure this out by looking for common failure messages in the logs. But, first, we need to load the logs into lnav. You can load all of the logs by passing the path to the Hammered directory along with the -r option to recurse through any subdirectories:

lnav -r Hammered

Now that the logs are loaded, you can use the .msgformats SQL command to execute a canned query that finds log messages with a common text format. (Unfortunately, this command has suffered from bitrot and is broken in the current release. It will be fixed in the next release. In the meantime, you can copy the snippet below to a file and execute it using the | prompt.) You can enter the SQL prompt by pressing ; and then entering the command or statement:

;.msgformats

The top results I get for this batch of logs look like the following.

┏━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃total┃log_line┃       log_time        ┃  duration  ┃    log_formats    ┃                                                   log_msg_format                                                   ┃
┡━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│15179│     798│2010-03-16 08:12:09.000│47d14h59m04s│syslog_log         │#): session closed for user root                                                                                    │
│14500│     817│2010-03-16 08:17:01.000│47d14h54m00s│syslog_log         │#): session opened for user root by (#)                                                                             │
│14480│   29380│2010-04-19 04:36:49.000│7d04h03m45s │syslog_log         │pam_unix(sshd:auth): #; #                                                                                           │
│14478│   29381│2010-04-19 04:36:49.000│7d04h03m45s │syslog_log         │#): #; logname= #                                                                                                   │
│ 6300│   74477│2010-04-20 06:57:11.000│6d03h00m42s │syslog_log         │: [#]: IN=# OUT=# MAC=# SRC=# DST=# LEN=# TOS=# PREC=# TTL=# ID=# PROTO=# SPT=# DPT=# LEN=#                         │
│ 5848│    4695│2010-03-18 11:38:04.000│38d21h13m39s│syslog_log         │#): #; logname= #                                                                                                   │
│ 5479│   16164│2010-03-29 13:23:46.000│27d19h27m58s│syslog_log         │Failed password for root from # port # #                                                                            │
...

The # in the log_msg_format column are the parts of the text that vary between log messages. For example, the most interesting message is “Failed password for root from # port # #”. In that case, the first # would be the IP address and then the port number. The first column indicates how many times a message like this was found, so 5,479 failed password attempts is probably a good sign of a breakin attempt.

To find out the service that logged this message, you can scroll down to focus on the message and then press Shift + Q to return to the LOG view at the line mentioned in the log_line column. In this case, line 16,164, which contains:

Mar 29 13:23:46 app-1 sshd[21492]: Failed password for root from 10.0.1.2 port 51771 ssh2

So, the attack vector is sshd.

msgformat.lnav

The ;.msgformats command has been broken for a few releases, but its functionality can be replicated using the script below. Copy the following to a file named msgformat.lnav and place it in the formats/installed lnav configuration directory.

;SELECT count(*) AS total,
       min(log_line) AS log_line,
       min(log_time) AS log_time,
       humanize_duration(timediff(max(log_time), min(log_time))) AS duration,
       group_concat(DISTINCT log_format) AS log_formats,
       log_msg_format
    FROM all_logs
    GROUP BY log_msg_format
    HAVING total > 1
    ORDER BY total DESC
:switch-to-view db

Q2: What is the operating system version of the targeted system? (one word)

The answer to this question has the form 4.*.*.u3 as given in the challenge. You can do a search in lnav by pressing / and then entering a PCRE-compatible regular expression. In this case, entering 4\.[^ ]+u3 will locate lines with the desired version number of 4.2.4-1ubuntu3.

Q3: What is the name of the compromised account?

Using the findings of our initial analysis, the compromised account is root.

Q4: Consider that each unique IP represents a different attacker. How many attackers were able to get access to the system?

Answering this question will require analyzing messages in the auth.log file. Specifically, we will need to find failed password attempts, like the following one and extract the user ID and IP address:

Apr 18 18:22:07 app-1 sshd[5266]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.151.246.140  user=root

The failed attempts will give us the attacker IP addresses. However, we don’t want to confuse attacker IPs with legitimate logins. So, we’ll need to look for successful login messages like this one:

Mar 16 08:26:06 app-1 sshd[4894]: Accepted password for user3 from 192.168.126.1 port 61474 ssh2

Analyzing log data in lnav is done through the SQL interface. The log messages can be accessed through SQL tables that are automatically defined for each log format. However, that is pretty cumbersome since there would be a lot of regex SQL function calls cluttering up the queries. Instead, we can use the :create-search-table command to create a SQL table that matches a regular expression against the log messages and extracts data into column(s). We can then write much simpler SQL queries to get the data we’re interested in.

First, lets create an auth_failures table for the authentication failure log messages:

:create-search-table auth_failures authentication failure; .* rhost=(?<ip>\d+\.\d+\.\d+\.\d+)\s+user=(?<user>[^ ]+)

Now, let’s try it out by finding the IPs of failed auth attempts:

;SELECT DISTINCT ip FROM auth_failures

Next, lets create an auth_accepted table for the successful authentications:

:create-search-table auth_accepted Accepted password for (?<user>[^ ]+) from (?<ip>\d+\.\d+\.\d+\.\d+)

Now that we have these two tables, we can write a query that gets the IPs of failed auth attempts that eventually succeeded. We further filter out low failure counts to eliminate human error. The full query is as follows:

;SELECT ip, count(*) AS co FROM auth_failures WHERE user = 'root' AND ip IN (SELECT DISTINCT ip FROM auth_accepted) GROUP BY ip HAVING co > 10

The results are the following six IPs:

┏━━━━━━━━━━━━━━━┳━━━━┓
┃      ip       ┃ co ┃
┡━━━━━━━━━━━━━━━╇━━━━┩
│61.168.227.12  │ 386│
│121.11.66.70   │2858│
│122.226.202.12 │ 626│
│219.150.161.20 │3120│
│222.66.204.246 │1016│
│222.169.224.197│ 358│
└━━━━━━━━━━━━━━━┴━━━━┘

Q5: Which attacker’s IP address successfully logged into the system the most number of times?

The attacker IPs were found using the query in the previous question, but the counts are for the number of failed auth attempts. Probably the easiest thing to do is create a SQL view with the previous query. That can be done quickly by pressing ; and then pressing the up arrow to go back in the command history. Then, go to the start of the line and prepend CREATE VIEW attackers AS before the SELECT. That will create an attackers SQL view that we can use to answer this question.

Now that we can easily get the list of attacker IPs, we can write a query for the auth_accepted table that finds all the successful auth messages. We then group by IP and count to get the data we want:

;SELECT ip, count(*) AS co FROM auth_accepted WHERE ip IN (SELECT ip FROM attackers) GROUP BY ip ORDER co DESC

The results are:

┏━━━━━━━━━━━━━━━┳━━┓
┃      ip       ┃co┃
┡━━━━━━━━━━━━━━━╇━━┩
│219.150.161.20 │ 4│
│122.226.202.12 │ 2│
│121.11.66.70   │ 2│
│222.169.224.197│ 1│
│222.66.204.246 │ 1│
│61.168.227.12  │ 1│
└━━━━━━━━━━━━━━━┴━━┘

The top IP there is 219.150.161.20.

Q6: How many requests were sent to the Apache Server?

Logs that follow the Apache log format can be accessed by the access_log SQL table. The following query will count the log messages in each access log file:

;SELECT log_path, count(*) FROM access_log GROUP BY log_path

The results I get are:

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┓
┃                       log_path                        ┃count(*)┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━┩
│/Users/tstack/Downloads/Hammered/apache2/www-access.log│     365│
│/Users/tstack/Downloads/Hammered/apache2/www-media.log │     229│
└━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┴━━━━━━━━┘

It seems like they want just what is in the www-access.log file, so the answer is 365.

Q7: How many rules have been added to the firewall?

Rules are added by the iptables -A command, so we can do a search for that command and the status bar will show “6 hits for “iptables -A””.

Q9: When was the last login from the attacker with IP 219.150.161.20? Format: MM/DD/YYYY HH:MM:SS AM

Using the auth_accepted table we created previously, this is a pretty simple query for max(log_time):

;SELECT max(log_time) FROM auth_accepted WHERE ip = '219.150.161.20'

The result I get is:

✔ SQL Result: 2010-04-19 05:56:05.000

Q10: The database displayed two warning messages, provide the most important and dangerous one.

The database log messages come out in the syslog with a procname of /etc/mysql/debian-start and are recognized as warnings. Using this, we can write a filter expression that filters the log based on SQL expression. For the syslog file format, the procname is accessible via the :log_procname variable and the log level is in the :log_level variable. The following command puts this together:

:filter-expr :log_procname = '/etc/mysql/debian-start' AND :log_level = 'warning'

After running this command, you should only see about 15 lines of the 100+k that was originally shown. Taking a look at these lines, the following line seems pretty bad:

Mar 18 10:18:42 app-1 /etc/mysql/debian-start[7566]: WARNING: mysql.user contains 2 root accounts without password!

To clear the filter, you can press CTRL + R to reset the state of the session.

Q12: Few attackers were using a proxy to run their scans. What is the corresponding user-agent used by this proxy?

The user-agent can be retrieved from the cs_user_agent column in the access_log table. The following query will get the unique user-agent names:

;SELECT DISTINCT cs_user_agent FROM access_log

The results I get are:

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                         cs_user_agent                                                          ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│Apple-PubSub/65.12.1                                                                                                            │
│Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)                                                                              │
│Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)                                                                              │
│iearthworm/1.0, iearthworm@yahoo.com.cn                                                                                         │
│Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1045 Safari/532.5          │
│WordPress/2.9.2; http://www.domain.org                                                                                          │
│Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19                                    │
│Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10│
│Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3                                 │
│pxyscand/2.1                                                                                                                    │
│-                                                                                                                               │
│Mozilla/4.0 (compatible; NaverBot/1.0; http://help.naver.com/customer_webtxt_02.jsp)                                            │
│Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7 │
│Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1059 Safari/532.5          │
└━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┘

The pxyscand/2.1 name seems to be the one they want.

Inspired by this blog post about reporting configuration file locations and the ensuing HackerNews commentary. I’ve added the config get and config blame management commands for getting the final configuration and the source of each property in the configuration, respectively. I had previously added the file locations used by lnav in the lnav -h output as recommended by the blog post. But, the HN comments made a good case for adding the the other troubleshooting tooling as well.

If you would like to try out these new commands, you need to run lnav with the -m option to switch to the “management” mode. For example, just running lnav with this flag will print out the available operations:

$ lnav -m
✘ error: expecting an operation to perform
 = help: the available operations are:
          • config: perform operations on the lnav configuration
          • format: perform operations on log file formats
          • piper: perform operations on piper storage
          • regex101: create and edit log message regular expressions using regex101.com

Executing config get will print out the final configuration that lnav is operating with as JSON:

$ lnav -m config get

If you would like to know the source of the value for each property, you can use the config blame command, like so:

$ lnav -m config blame | tail
/ui/theme-defs/solarized-light/vars/black -> solarized-light.json:15
/ui/theme-defs/solarized-light/vars/blue -> solarized-light.json:21
/ui/theme-defs/solarized-light/vars/cyan -> solarized-light.json:22
/ui/theme-defs/solarized-light/vars/green -> solarized-light.json:23
/ui/theme-defs/solarized-light/vars/magenta -> solarized-light.json:19
/ui/theme-defs/solarized-light/vars/orange -> solarized-light.json:17
/ui/theme-defs/solarized-light/vars/red -> solarized-light.json:18
/ui/theme-defs/solarized-light/vars/semantic_highlight_color -> solarized-light.json:24
/ui/theme-defs/solarized-light/vars/violet -> solarized-light.json:20
/ui/theme-defs/solarized-light/vars/yellow -> solarized-light.json:16

In the above output, “solarized-light.json” file is built into the lnav executable and is not from the file system.

The major change in the v0.11.2 release is the addition of a “cursor mode” for the main view. Instead of focusing on the top line for interacting with lnav, a cursor line is displayed and interactions focus on that. The arrow keys and the hotkeys that jump between bookmarks, like search hits and errors, now move the focused line instead of scrolling the view. To help provide context for what you’re looking at, large jumps will keep the focused line in the middle of the view. Smaller movements, like moving the cursor above the top line, will scroll the view a small amount so as not to be jarring.

You can enable/disable cursor mode interactively by pressing CTRL + x. Or, you can permanently enable cursor mode by running the following :config command:

:config /ui/movement/mode cursor

The lnav commands, those prefixed with colons, are marked as keywords and the SQL blocks are treated as an embedded language and highlighted accordingly.

If people find this useful, we can take it further and add support for running the current script/snippet in a new lnav process or even talking to an existing one.

$ ssh playground@demo.lnav.org
$ ssh tutorial1@demo.lnav.org

The playground has a couple of example logs to play with. The tutorial tries to guide you through the basics of navigating log files with lnav. The server is running on the free-tier of fly.io, so please be kind.

This effort was inspired by the git.charm.sh SSH server and by the fasterthanli.me post on doing remote development on fly.io.

As part of the effort to polish the lnav TUI, I wanted to make the builtin help text look a bit nicer. The current help text is a plain text file with some ANSI escape sequences for colors. It’s not easy to write or read. Since Markdown has become a dominant way to write this type of document, I figured I could use that and have the side benefit of allowing lnav to read Markdown docs. Fortunately, the MD4C library exists. This library provides a nice event-driven parser for documents instead of just converting directly to HTML. In addition, document structure is now shown/navigable through the new breadcrumb bar at the top. I think the result is pretty nice:

Viewing Markdown Files

Files with an .md suffix will be considered as Markdown and will be parsed as such. As an example, here is lnav displaying its README.md file:

Taking a page from compilers like rustc, I’ve spent some time improving error messages to make them look nicer and be more helpful. Fortunately, SQLite has improved their error reporting as well by adding sqlite3_error_offset(). This function can point to the part of the SQL statement that was in error. As an example of the improvement, a SQL file that contained the following content:

-- This is a test
SELECT abc),
rtrim(def)
FROM mytable;

Would report an error like the following on startup in v0.10.1:

error:/Users/tstack/.config/lnav/formats/installed/test.sql:2:near ")": syntax error

Now, you will get a clearer error message with a syntax-highlighted code snippet and a pointer to the part of the code that has the problem:

Inside the TUI, a panel has been added at the bottom to display these long-form error messages. The panel will disappear after a short time or when input is received. Here is an example showing an error for an invalid regular expression:

Creating and updating format files for lnav can be a bit tedious and error-prone. To help streamline the process, an integration with regex101.com has been added. Now, you can create regular expressions for plaintext log files on https://regex101.com and then create a skeleton format file with a simple command. If you already have a format file that needs to be updated, you can push the regexes up to regex101, edit them with their interface, and then pull the changes back down as a format patch file.

To further improve the experience of developing with format files, there is also work underway to improve error messages. Many messages should be clearer, more context is provided, and they should look nicer as well. For example, the following error is displayed when a format regex is not valid:

Management CLI

The regex101 integration can be accessed through the new “management-mode CLI”. This mode can be accessed by passing -m as the first option to lnav. The management CLI is organized as a series of nested commands. If you’re not sure what to do at a given level, run the command as-is and the CLI should print out help text to guide you through the hierarchy of commands and required parameters.

Create a format from a regular expression

The regex101 import command can be used to import a regular expression from regex101.com and create or patch a format file. The command takes the URL of the regex, the format name, and the name of the regex in the log format ( defaults to “std” if not given). For example, the following command can be used to import the regex at “https://regex101.com/r/zpEnjV/2” into the format named “ re101_example_log”:

$ lnav -m regex101 import https://regex101.com/r/zpEnjV/2 re101_example_log

If the import was successful, the path to the skeleton format file will be printed. You will most likely need to edit the file to fill in more details about your log format.

Editing an existing regular expression

If you have a log format with a regex that needs to be updated, you can push the regex to regex101.com for editing with a command like (replace “myformat_log”/”std” with the name of your format and regex):

$ lnav -m format myformat_log regex std regex101 push

Along with the regex, the format’s samples will be added to the entry to ensure changes won’t break existing matches. If the push was successful, the URL for the new regex101.com entry will be printed out. You can use that URL to edit the regex to your needs. Once you’re done editing the regex, you can pull the changes down to a “patch” file using the following command:

$ lnav -m format myformat_log regex std regex101 pull

The patch file will be evaluated after the original format file and override the values from the original. Once you are satisfied with the changes, you can move the contents of the patch file to the original file and delete the patch.