mirror of
https://github.com/kellyjonbrazil/jc.git
synced 2025-06-17 00:07:37 +02:00
formatting
This commit is contained in:
@ -225,6 +225,7 @@ JC_COLORS=default,default,default,default
|
|||||||
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` and `ping-s`) that start processing and outputing the data line-by-line as [JSON Lines](https://jsonlines.org/) (aka [NDJSON](http://ndjson.org/)) while it is being received from STDIN. Streaming parsers have slightly different behavior than standard parsers as outlined below.
|
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` and `ping-s`) that start processing and outputing the data line-by-line as [JSON Lines](https://jsonlines.org/) (aka [NDJSON](http://ndjson.org/)) while it is being received from STDIN. Streaming parsers have slightly different behavior than standard parsers as outlined below.
|
||||||
|
|
||||||
**Ignoring Errors**
|
**Ignoring Errors**
|
||||||
|
|
||||||
When using streaming parsers you may want to ignore parsing errors since these may be used in a long-lived processing pipeline and errors can break the pipe. To ignore parsing errors, use the `-q` cli option or `quiet=True` argument to the `parse()` function. This will add a `_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:
|
When using streaming parsers you may want to ignore parsing errors since these may be used in a long-lived processing pipeline and errors can break the pipe. To ignore parsing errors, use the `-q` cli option or `quiet=True` argument to the `parse()` function. This will add a `_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:
|
||||||
|
|
||||||
Successfully parsed line with `-q` option:
|
Successfully parsed line with `-q` option:
|
||||||
@ -248,6 +249,7 @@ Unsuccessfully parsed line with `-q` option:
|
|||||||
```
|
```
|
||||||
|
|
||||||
**Unbuffering Output**
|
**Unbuffering Output**
|
||||||
|
|
||||||
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`):
|
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
|
$ ping 1.1.1.1 | jc --ping-s | jq
|
||||||
@ -262,7 +264,6 @@ $ ping 1.1.1.1 | jc --ping-s -u | jq
|
|||||||
```
|
```
|
||||||
> Note: Unbuffered output can be slower for faster data streams.
|
> Note: Unbuffered output can be slower for faster data streams.
|
||||||
|
|
||||||
|
|
||||||
### Custom Parsers
|
### Custom Parsers
|
||||||
Custom local parser plugins may be placed in a `jc/jcparsers` folder in your local **"App data directory"**:
|
Custom local parser plugins may be placed in a `jc/jcparsers` folder in your local **"App data directory"**:
|
||||||
|
|
||||||
|
@ -150,6 +150,7 @@ JC_COLORS=default,default,default,default
|
|||||||
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` and `ping-s`) that start processing and outputing the data line-by-line as [JSON Lines](https://jsonlines.org/) (aka [NDJSON](http://ndjson.org/)) while it is being received from STDIN. Streaming parsers have slightly different behavior than standard parsers as outlined below.
|
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` and `ping-s`) that start processing and outputing the data line-by-line as [JSON Lines](https://jsonlines.org/) (aka [NDJSON](http://ndjson.org/)) while it is being received from STDIN. Streaming parsers have slightly different behavior than standard parsers as outlined below.
|
||||||
|
|
||||||
**Ignoring Errors**
|
**Ignoring Errors**
|
||||||
|
|
||||||
When using streaming parsers you may want to ignore parsing errors since these may be used in a long-lived processing pipeline and errors can break the pipe. To ignore parsing errors, use the `-q` cli option or `quiet=True` argument to the `parse()` function. This will add a `_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:
|
When using streaming parsers you may want to ignore parsing errors since these may be used in a long-lived processing pipeline and errors can break the pipe. To ignore parsing errors, use the `-q` cli option or `quiet=True` argument to the `parse()` function. This will add a `_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:
|
||||||
|
|
||||||
Successfully parsed line with `-q` option:
|
Successfully parsed line with `-q` option:
|
||||||
@ -173,6 +174,7 @@ Unsuccessfully parsed line with `-q` option:
|
|||||||
```
|
```
|
||||||
|
|
||||||
**Unbuffering Output**
|
**Unbuffering Output**
|
||||||
|
|
||||||
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`):
|
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
|
$ ping 1.1.1.1 | jc --ping-s | jq
|
||||||
@ -187,7 +189,6 @@ $ ping 1.1.1.1 | jc --ping-s -u | jq
|
|||||||
```
|
```
|
||||||
> Note: Unbuffered output can be slower for faster data streams.
|
> Note: Unbuffered output can be slower for faster data streams.
|
||||||
|
|
||||||
|
|
||||||
### Custom Parsers
|
### Custom Parsers
|
||||||
Custom local parser plugins may be placed in a `jc/jcparsers` folder in your local **"App data directory"**:
|
Custom local parser plugins may be placed in a `jc/jcparsers` folder in your local **"App data directory"**:
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user