jc(1) | JSON Convert | jc(1) |
jc - JSON Convert JSONifies the output of many CLI tools, file-types, and strings
Standard syntax:
cat FILE | jc [OPTIONS] PARSER
echo STRING | jc [OPTIONS] PARSER
Magic syntax:
jc [OPTIONS] /proc/<path-to-procfile>
jc JSONifies the output of many CLI tools, file-types, and common strings for easier parsing in scripts. jc accepts piped input from STDIN and outputs a JSON representation of the previous command's output to STDOUT. Alternatively, the "Magic" syntax can be used by prepending jc to the command to be converted. Options can be passed to jc immediately before the command is given. (Note: "Magic" syntax does not support shell builtins or command aliases)
Parsers:
Options:
Any fatal errors within jc will generate an exit code of 100, otherwise the exit code will be 0.
When using the "magic" syntax (e.g. jc ifconfig eth0), jc will store the exit code of the program being parsed and add it to the jc exit code. This way it is easier to determine if an error was from the parsed program or jc.
Consider the following examples using ifconfig:
ifconfig exit code = 1, jc exit code = 0, combined exit code = 1 (error in ifconfig)
ifconfig exit code = 0, jc exit code = 100, combined exit code = 100 (error in jc)
ifconfig exit code = 1, jc exit code = 100, combined exit code = 101 (error in both ifconfig and jc)
When using the "magic" syntax you can also retrieve the exit code of the called program by using the --meta-out or -M option. This will append a _jc_meta object to the output that will include the magic command information, including the exit code.
Here is an example with ping:
$ jc --meta-out -p ping -c2 192.168.1.252 {
"destination_ip": "192.168.1.252",
"data_bytes": 56,
"pattern": null,
"destination": "192.168.1.252",
"packets_transmitted": 2,
"packets_received": 0,
"packet_loss_percent": 100.0,
"duplicates": 0,
"responses": [
{
"type": "timeout",
"icmp_seq": 0,
"duplicate": false
}
],
"_jc_meta": {
"parser": "ping",
"timestamp": 1661357115.27949,
"magic_command": [
"ping",
"-c2",
"192.168.1.252"
],
"magic_command_exit": 2
} } $ echo $? 2
Custom Colors
You can specify custom colors via the JC_COLORS environment variable. The JC_COLORS environment variable takes four comma separated string values in the following format:
JC_COLORS=<keyname_color>,<keyword_color>,<number_color>,<string_color>
Where colors are: black, red, green, yellow, blue, magenta, cyan, gray, brightblack, brightred, brightgreen, brightyellow, brightblue, brightmagenta, brightcyan, white, or default
For example, to set to the default colors:
or
JC_COLORS=default,default,default,default
Disable Color Output
You can set the NO_COLOR environment variable to any value to disable color output in jc. Note that using the -C option to force color output will override both the NO_COLOR environment variable and the -m option.
Most parsers load all of the data from STDIN, parse it, then output the entire JSON document serially. There are some streaming parsers (e.g. ls-s, ping-s, etc.) that immediately start processing and outputting the data line-by-line as JSON Lines (aka NDJSON) while it is being received from STDIN. This can significantly reduce the amount of memory required to parse large amounts of command output (e.g. ls -lR /) and can sometimes process the data more quickly. Streaming parsers have slightly different behavior than standard parsers as outlined below.
Ignoring Errors
You may want to ignore parsing errors when using streaming parsers since these may be used in long-lived processing pipelines and errors can break the pipe. To ignore parsing errors, use the -qq cli option. This will add a _jc_meta object to the JSON output with a success attribute. If success is true, then there were no issues parsing the line. If success is false, then a parsing issue was found and error and line fields will be added to include a short error description and the contents of the unparsable line, respectively:
{
"command_data": "data",
"_jc_meta": {
"success": true
} }
Unsuccessfully parsed line with -qq option:
{
"_jc_meta": {
"success": false,
"error": "error message",
"line": "original line data"
} }
Most operating systems will buffer output that is being piped from process to process. The buffer is usually around 4KB. When viewing the output in the terminal the OS buffer is not engaged so output is immediately displayed on the screen. When piping multiple processes together, though, it may seem as if the output is hanging when the input data is very slow (e.g. ping):
$ ping 1.1.1.1 | jc --ping-s | jq <slow output>
This is because the OS engages the 4KB buffer between jc and jq in this example. To display the data on the terminal in realtime, you can disable the buffer with the -u (unbuffer) cli option:
$ ping 1.1.1.1 | jc --ping-s -u | jq {"type":"reply","pattern":null,"timestamp":null,"bytes":"64",...} {"type":"reply","pattern":null,"timestamp":null,"bytes":"64",...} etc...
Note: Unbuffered output can be slower for large data streams.
Custom local parser plugins may be placed in a jc/jcparsers folder in your local "App data directory":
- Linux/unix: $HOME/.local/share/jc/jcparsers - macOS: $HOME/Library/Application Support/jc/jcparsers - Windows: $LOCALAPPDATA\jc\jc\jcparsers
Local parser plugins are standard python module files. Use the jc/parsers/foo.py or jc/parsers/foo_s.py (streaming) parser as a template and simply place a .py file in the jcparsers subfolder.
Local plugin filenames must be valid python module names and therefore must start with a letter and consist entirely of alphanumerics and underscores. Local plugins may override default parsers.
Note: The application data directory follows the XDG Base Directory Specification
Locale
For best results set the locale environment variables to C or en_US.UTF-8 by modifying the LC_ALL variable:
You can also set the locale variables individually:
$ export LC_NUMERIC=C
On some older systems UTF-8 output will be downgraded to ASCII with \u escape sequences if the C locale does not support UTF-8 encoding.
Timezones
Some parsers have calculated epoch timestamp fields added to the output. Unless a timestamp field name has a _utc suffix it is considered naive. (i.e. based on the local timezone of the system the jc parser was run on).
If a UTC timezone can be detected in the text of the command output, the timestamp will be timezone aware and have a _utc suffix on the key name. (e.g. epoch_utc) No other timezones are supported for aware timestamps.
Standard Syntax:
$ cat /proc/meminfo | jc --pretty --proc
Magic Syntax:
$ jc --pretty /proc/meminfo
For parser documentation:
Kelly Brazil (kellyjonbrazil@gmail.com)
https://github.com/kellyjonbrazil/jc
Copyright (c) 2019-2023 Kelly Brazil
License: MIT License
2023-01-11 | 1.22.5 |