mirror of
https://github.com/johnkerl/miller.git
synced 2026-08-02 12:32:21 +00:00
408 lines
18 KiB
HTML
408 lines
18 KiB
HTML
POKI_PUT_TOC_HERE
|
|
|
|
<p/>
|
|
<button style="font-weight:bold;color:maroon;border:0" onclick="bodyToggler.expandAll();" href="javascript:;">Expand all sections</button>
|
|
<button style="font-weight:bold;color:maroon;border:0" onclick="bodyToggler.collapseAll();" href="javascript:;">Collapse all sections</button>
|
|
|
|
<h1>Overview</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_overview');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_overview" style="display: block">
|
|
|
|
<p/>Miller handles name-indexed data using several formats: some you probably
|
|
know by name, such as CSV, TSV, and JSON — and other formats you’re
|
|
likely already seeing and using in your structured data. Additionally, Miller gives
|
|
you the option of including comments within your data.
|
|
|
|
</div>
|
|
<h1>Examples</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_examples');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_examples" style="display: block">
|
|
|
|
POKI_RUN_COMMAND{{mlr --usage-data-format-examples}}HERE
|
|
|
|
</div>
|
|
<h1>CSV/TSV/ASV/USV/etc.</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_csv_tsv_etc');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_csv_tsv_etc" style="display: block">
|
|
|
|
<p/>
|
|
When <code>mlr</code> is invoked with the <code>--csv</code> or <code>--csvlite</code> option,
|
|
key names are found on the first record and values are taken from subsequent
|
|
records. This includes the case of CSV-formatted files. See
|
|
POKI_PUT_LINK_FOR_PAGE(record-heterogeneity.html)HERE for how Miller handles
|
|
changes of field names within a single data stream.
|
|
|
|
<p/> Miller has record separator <code>RS</code> and field separator <code>FS</code>,
|
|
just as <code>awk</code> does. For TSV, use <code>--fs tab</code>; to convert TSV to
|
|
CSV, use <code>--ifs tab --ofs comma</code>, etc. (See also
|
|
POKI_PUT_LINK_FOR_PAGE(reference.html#Record/field/pair_separators)HERE.)
|
|
|
|
<p/> <b>TSV (tab-separated values):</b> the following are synonymous pairs:
|
|
<ul>
|
|
<li/> <code>--tsv</code> and <code>--csv --fs tab</code>
|
|
<li/> <code>--itsv</code> and <code>--icsv --ifs tab</code>
|
|
<li/> <code>--otsv</code> and <code>--ocsv --ofs tab</code>
|
|
<li/> <code>--tsvlite</code> and <code>--csvlite --fs tab</code>
|
|
<li/> <code>--itsvlite</code> and <code>--icsvlite --ifs tab</code>
|
|
<li/> <code>--otsvlite</code> and <code>--ocsvlite --ofs tab</code>
|
|
</ul>
|
|
|
|
<p/> <b>ASV (ASCII-separated values):</b> the flags
|
|
<code>--asv</code>,
|
|
<code>--iasv</code>,
|
|
<code>--oasv</code>,
|
|
<code>--asvlite</code>,
|
|
<code>--iasvlite</code>, and
|
|
<code>--oasvlite</code> are analogous except they use ASCII FS and RS 0x1f and 0x1e, respectively.
|
|
|
|
<p/> <b>USV (Unicode-separated values):</b> likewise, the flags
|
|
<code>--usv</code>,
|
|
<code>--iusv</code>,
|
|
<code>--ousv</code>,
|
|
<code>--usvlite</code>,
|
|
<code>--iusvlite</code>, and
|
|
<code>--ousvlite</code> use Unicode FS and RS U+241F (UTF-8 0x0xe2909f) and U+241E (UTF-8 0xe2909e), respectively.
|
|
|
|
<p/>Miller’s <code>--csv</code> flag supports RFC-4180 CSV (<a href="https://tools.ietf.org/html/rfc4180">
|
|
https://tools.ietf.org/html/rfc4180</a>). This includes CRLF line-terminators by default, regardless
|
|
of platform.
|
|
|
|
<p/>Here are the differences between CSV and CSV-lite:
|
|
|
|
<ul>
|
|
|
|
<li/>CSV supports <a href="https://tools.ietf.org/html/rfc4180">
|
|
RFC-4180</a>)-style double-quoting, including the ability to have commas and/or
|
|
LF/CRLF line-endings contained within an input field; CSV-lite does not.
|
|
|
|
<li/>CSV does not allow heterogeneous data; CSV-lite does (see also <a
|
|
href="record-heterogeneity.html">here</a>).
|
|
|
|
<li/>The CSV-lite input-reading code is fractionally more efficient than the CSV
|
|
input-reader.
|
|
|
|
</ul>
|
|
|
|
<p/>Here are things they have in common:
|
|
|
|
<ul>
|
|
|
|
<li/>The ability to specify record/field separators other than the default,
|
|
e.g. CR-LF vs. LF, or tab instead of comma for TSV, and so on.
|
|
|
|
<li/>The <code>--implicit-csv-header</code> flag for input and the
|
|
<code>--headerless-csv-output</code> flag for output.
|
|
|
|
</ul>
|
|
|
|
</div>
|
|
<h1>DKVP: Key-value pairs</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_dkvp');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_dkvp" style="display: block">
|
|
|
|
<p/>
|
|
Miller’s default file format is DKVP, for <b>delimited key-value pairs</b>. Example:
|
|
|
|
POKI_RUN_COMMAND{{mlr cat data/small}}HERE
|
|
|
|
Such data are easy to generate, e.g. in Ruby with
|
|
POKI_CARDIFY(puts "host=#{hostname},seconds=#{t2-t1},message=#{msg}")HERE
|
|
POKI_CARDIFY{{puts mymap.collect{|k,v| "#{k}=#{v}"}.join(',')}}HERE
|
|
or <code>print</code> statements in various languages, e.g.
|
|
POKI_CARDIFY(echo "type=3,user=$USER,date=$date\n";)HERE
|
|
POKI_CARDIFY{{logger.log("type=3,user=$USER,date=$date\n");}}HERE
|
|
|
|
<p/>Fields lacking an IPS will have positional index (starting at 1) used as
|
|
the key, as in NIDX format. For example, <code>dish=7,egg=8,flint</code> is parsed
|
|
as <code>"dish" => "7", "egg" => "8", "3" => "flint"</code> and
|
|
<code>dish,egg,flint</code> is parsed as <code>"1" => "dish", "2" => "egg", "3"
|
|
=> "flint"</code>.
|
|
|
|
<p/> As discussed in POKI_PUT_LINK_FOR_PAGE(record-heterogeneity.html)HERE,
|
|
Miller handles changes of field names within the same data stream. But using
|
|
DKVP format this is particularly natural. One of my favorite use-cases for
|
|
Miller is in application/server logs, where I log all sorts of lines such as
|
|
|
|
<p/>
|
|
<div class="pokipanel">
|
|
<pre>
|
|
resource=/path/to/file,loadsec=0.45,ok=true
|
|
record_count=100, resource=/path/to/file
|
|
resource=/some/other/path,loadsec=0.97,ok=false
|
|
</pre>
|
|
</div>
|
|
<p/>
|
|
|
|
etc. and I just log them as needed. Then later, I can use <code>grep</code>, <code>mlr --opprint group-like</code>, etc.
|
|
to analyze my logs.
|
|
|
|
<p/>See POKI_PUT_LINK_FOR_PAGE(reference.html)HERE regarding how to specify separators other than
|
|
the default equals-sign and comma.
|
|
|
|
</div>
|
|
<h1>NIDX: Index-numbered (toolkit style)</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_nidx');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_nidx" style="display: block">
|
|
|
|
With <code>--inidx --ifs ' ' --repifs</code>, Miller splits lines on whitespace and
|
|
assigns integer field names starting with 1. This recapitulates Unix-toolkit
|
|
behavior.
|
|
|
|
<p/> Example with index-numbered output:
|
|
|
|
<table><tr> <td>
|
|
POKI_RUN_COMMAND{{cat data/small}}HERE
|
|
</td> <td>
|
|
POKI_RUN_COMMAND{{mlr --onidx --ofs ' ' cat data/small}}HERE
|
|
</td> </tr></table>
|
|
|
|
<p/> Example with index-numbered input:
|
|
|
|
<table><tr> <td>
|
|
POKI_RUN_COMMAND{{cat data/mydata.txt}}HERE
|
|
</td> <td>
|
|
POKI_RUN_COMMAND{{mlr --inidx --ifs ' ' --odkvp cat data/mydata.txt}}HERE
|
|
</td> </tr></table>
|
|
|
|
<p/> Example with index-numbered input and output:
|
|
|
|
<table><tr> <td>
|
|
POKI_RUN_COMMAND{{cat data/mydata.txt}}HERE
|
|
</td> <td>
|
|
POKI_RUN_COMMAND{{mlr --nidx --fs ' ' --repifs cut -f 2,3 data/mydata.txt}}HERE
|
|
</td> </tr></table>
|
|
|
|
</div>
|
|
<h1>Tabular JSON</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_json');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_json" style="display: block">
|
|
|
|
<p/>JSON is a format which supports arbitrarily deep nesting of
|
|
“objects” (hashmaps) and “arrays” (lists), while Miller
|
|
is a tool for handling <span class="boldmaroon">tabular data</span> only. This means
|
|
Miller cannot (and should not) handle arbitrary JSON. (Check out <a
|
|
href="http://stedolan.github.io/jq/">jq</a>.)
|
|
|
|
<p/>But if you have tabular data represented in JSON then Miller can handle that for you.
|
|
|
|
<h2>Single-level JSON objects</h2>
|
|
|
|
An <span class="boldmaroon">array of single-level objects</span> is, quite simply,
|
|
<span class="boldmaroon">a table:</span>
|
|
|
|
POKI_RUN_COMMAND{{mlr --json head -n 2 then cut -f color,shape data/json-example-1.json}}HERE
|
|
POKI_RUN_COMMAND{{mlr --json --jvstack head -n 2 then cut -f color,u,v data/json-example-1.json}}HERE
|
|
POKI_RUN_COMMAND{{mlr --ijson --opprint stats1 -a mean,stddev,count -f u -g shape data/json-example-1.json}}HERE
|
|
|
|
<h2>Nested JSON objects</h2>
|
|
|
|
<p/>Additionally, Miller can <span class="boldmaroon">tabularize nested objects by concatentating keys:</span>
|
|
|
|
POKI_RUN_COMMAND{{mlr --json --jvstack head -n 2 data/json-example-2.json}}HERE
|
|
POKI_RUN_COMMAND{{mlr --ijson --opprint head -n 4 data/json-example-2.json}}HERE
|
|
|
|
<p/>Note in particular that as far as Miller’s <code>put</code> and <code>filter</code>, as well as other
|
|
I/O formats, are concerned, these are simply field names with colons in them:
|
|
|
|
POKI_RUN_COMMAND{{mlr --json --jvstack head -n 1 then put '${values:uv} = ${values:u} * ${values:v}' data/json-example-2.json}}HERE
|
|
|
|
<h2>Arrays</h2>
|
|
|
|
<p/>Arrays aren’t supported in Miller’s
|
|
<code>put</code>/<code>filter</code> DSL. By default, JSON arrays are read in as
|
|
integer-keyed maps.
|
|
|
|
<p/> Suppose you have arrays like this in our input data:
|
|
|
|
POKI_RUN_COMMAND{{cat data/json-example-3.json}}HERE
|
|
|
|
<p/> Then integer indices (starting from 0 and counting up) are used as map keys:
|
|
|
|
POKI_RUN_COMMAND{{mlr --ijson --oxtab cat data/json-example-3.json}}HERE
|
|
|
|
<p/> When the data are written back out as JSON, field names are re-expanded as above,
|
|
but what were arrays on input are now maps on output:
|
|
|
|
POKI_RUN_COMMAND{{mlr --json --jvstack cat data/json-example-3.json}}HERE
|
|
|
|
<p/> This is non-ideal, but it allows Miller (5.x release being latest as of
|
|
this writing) to handle JSON arrays at all.
|
|
|
|
<p/>You might also use <code>mlr --json-skip-arrays-on-input</code> or <code>mlr
|
|
--json-fatal-arrays-on-input</code>.
|
|
|
|
To truly handle JSON, please use a JSON-processing tool such as <a
|
|
href="http://stedolan.github.io/jq/">jq</a>.
|
|
|
|
<h2>Formatting JSON options</h2>
|
|
|
|
<p/>JSON isn’t a parameterized format, so <code>RS</code>, <code>FS</code>,
|
|
<code>PS</code> aren’t specifiable. Nonetheless, you can do the following:
|
|
|
|
<ul>
|
|
|
|
<li/>Use <code>--jvstack</code> to pretty-print JSON objects with multi-line
|
|
(vertically stacked) spacing. By default, each Miller record (JSON object) is
|
|
one per line.
|
|
|
|
<li/>Keystroke-savers:
|
|
<code>--jsonx</code> simply means <code>--json --jvstack</code>, and
|
|
<code>--ojsonx</code> simply means <code>--ojson --jvstack</code>.
|
|
|
|
<li/>Use <code>--jlistwrap</code> to print the sequence of JSON objects wrapped in
|
|
an outermost <code>[</code> and <code>]</code>. By default, these aren’t printed.
|
|
|
|
<li/>Use <code>--jquoteall</code> to double-quote all object values. By default,
|
|
integers, floating-point numbers, and booleans <code>true</code> and <code>false</code>
|
|
are not double-quoted when they appear as JSON-object keys.
|
|
|
|
<li/>Use <code>--jflatsep yourstringhere</code> to specify the string used for
|
|
key concatenation: this defaults to a single colon.
|
|
|
|
<li/>Use <code>--jofmt</code> to force Miller to apply the global <code>--ofmt</code>
|
|
to floating-point values. First note: please use sprintf-style codes for
|
|
double precision, e.g. ending in <code>%lf</code>, <code>%le</code>, or <code>%lg</code>.
|
|
Miller floats are double-precision so behavior using <code>%f</code>, <code>%d</code>,
|
|
etc. is undefined. Second note: <code>0.123</code> is valid JSON; <code>.123</code> is
|
|
not. Thus this feature allows you to emit JSON which may be unparseable by
|
|
other tools.
|
|
|
|
</ul>
|
|
|
|
<p/>Again, please see <a href="http://stedolan.github.io/jq/">jq</a> for a
|
|
truly powerful, JSON-specific tool.
|
|
|
|
<h2>JSON non-streaming</h2>
|
|
|
|
<p/>The JSON parser Miller uses does not return until all input is parsed: in
|
|
particular this means that, unlike for other file formats, Miller does not (at
|
|
present) handle JSON files in <code>tail -f</code> contexts.
|
|
|
|
</div>
|
|
<h1>PPRINT: Pretty-printed tabular</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_pprint');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_pprint" style="display: block">
|
|
|
|
<p/>
|
|
Miller’s pretty-print format is like CSV, but column-aligned. For example, compare
|
|
|
|
<table><tr><td>
|
|
POKI_RUN_COMMAND{{mlr --ocsv cat data/small}}HERE
|
|
</td>
|
|
<td>
|
|
POKI_RUN_COMMAND{{mlr --opprint cat data/small}}HERE
|
|
</td></tr></table>
|
|
|
|
Note that while Miller is a line-at-a-time processor and retains input lines in
|
|
memory only where necessary (e.g. for sort), pretty-print output requires it to
|
|
accumulate all input lines (so that it can compute maximum column widths)
|
|
before producing any output. This has two consequences: (a) pretty-print output
|
|
won’t work on <code>tail -f</code> contexts, where Miller will be waiting for
|
|
an end-of-file marker which never arrives; (b) pretty-print output for large
|
|
files is constrained by available machine memory.
|
|
|
|
<p/> See POKI_PUT_LINK_FOR_PAGE(record-heterogeneity.html)HERE for how Miller
|
|
handles changes of field names within a single data stream.
|
|
|
|
<p/> For output only (this isn’t supported in the input-scanner as of 5.0.0)
|
|
you can use <code>--barred</code> with pprint output format:
|
|
|
|
POKI_RUN_COMMAND{{mlr --opprint --barred cat data/small}}HERE
|
|
|
|
</div>
|
|
<h1>XTAB: Vertical tabular</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_xtab');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_xtab" style="display: block">
|
|
|
|
<p/>This is perhaps most useful for looking a very wide and/or multi-column
|
|
data which causes line-wraps on the screen (but see also <a
|
|
href="https://github.com/twosigma/ngrid">https://github.com/twosigma/ngrid</a>
|
|
for an entirely different, very powerful option). Namely:
|
|
|
|
<table><tr> <td>
|
|
POKI_INCLUDE_ESCAPED(data/system-file-opprint-example.txt)HERE
|
|
</td></tr> <tr><td>
|
|
POKI_INCLUDE_ESCAPED(data/system-file-oxtab-example.txt)HERE
|
|
</td></tr> <tr><td>
|
|
POKI_INCLUDE_ESCAPED(data/system-file-ojson-example.txt)HERE
|
|
</td> </tr></table>
|
|
|
|
</div>
|
|
<h1>Markdown tabular</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_markdown_tabular');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_markdown_tabular" style="display: block">
|
|
|
|
<p/>Markdown format looks like this:
|
|
|
|
POKI_RUN_COMMAND{{mlr --omd cat data/small}}HERE
|
|
|
|
which renders like this when dropped into various web tools (e.g. github comments):
|
|
|
|
<p/>
|
|
<img src="pix/omd.png"/>
|
|
|
|
<p/> As of Miller 4.3.0, markdown format is supported only for output, not input.
|
|
|
|
</div>
|
|
<h1>Data-conversion keystroke-savers</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_x2y');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_x2y" style="display: block">
|
|
|
|
<p/>While you can do format conversion using <code>mlr --icsv --ojson cat myfile.csv</code>,
|
|
there are also keystroke-savers for this purpose, such as <code>mlr --c2j cat myfile.csv</code>.
|
|
For a complete list:
|
|
|
|
POKI_RUN_COMMAND{{mlr --usage-format-conversion-keystroke-saver-options}}HERE
|
|
|
|
</div>
|
|
|
|
</div>
|
|
<h1>Autodetect of line endings</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_autodetect_line_endings');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_autodetect_line_endings" style="display: block">
|
|
|
|
<p/> Default line endings (<code>--irs</code> and <code>--ors</code>) are <code>'auto'</code>
|
|
which means <span class="boldmaroon">autodetect from the input file format</span>, as
|
|
long as the input file(s) have lines ending in either LF (also known as
|
|
linefeed, <code>'\n'</code>, <code>0x0a</code>, Unix-style) or CRLF (also known as
|
|
carriage-return/linefeed pairs, <code>'\r\n'</code>, <code>0x0d 0x0a</code>, Windows
|
|
style).
|
|
|
|
<p/> <span class="boldmaroon">If both IRS and ORS are auto (which is the default) then LF input will
|
|
lead to LF output and CRLF input will lead to CRLF output, regardless of the
|
|
platform you’re running on</span>.
|
|
|
|
<p/> The line-ending autodetector triggers on the first line ending detected in
|
|
the input stream. E.g. if you specify a CRLF-terminated file on the command
|
|
line followed by an LF-terminated file then autodetected line endings will be
|
|
CRLF.
|
|
|
|
<p/> If you use <code>--ors {something else}</code> with (default or explicitly
|
|
specified) <code>--irs auto</code> then line endings are autodetected on input and
|
|
set to what you specify on output.
|
|
|
|
<p/> If you use <code>--irs {something else}</code> with (default or explicitly
|
|
specified) <code>--ors auto</code> then the output line endings used are LF on
|
|
Unix/Linux/BSD/MacOSX, and CRLF on Windows.
|
|
|
|
<p/> See also
|
|
POKI_PUT_LINK_FOR_PAGE(reference.html#Record/field/pair_separators)HERE for
|
|
more information about record/field/pair separators.
|
|
|
|
</div>
|
|
<h1>Comments in data</h1>
|
|
<button style="font-weight:bold;color:maroon;border:0" padding=0 onclick="bodyToggler.toggle('body_section_toggle_comments_in_data');" href="javascript:;">Toggle section visibility</button>
|
|
<div id="body_section_toggle_comments_in_data" style="display: block">
|
|
|
|
<p/>You can include comments within your data files, and either have them ignored, or passed directly
|
|
through to the standard output as soon as they are encountered:
|
|
|
|
POKI_RUN_COMMAND{{mlr --usage-comments-in-data}}HERE
|
|
|
|
<p/>Examples:
|
|
|
|
POKI_RUN_COMMAND{{cat data/budget.csv}}HERE
|
|
POKI_RUN_COMMAND{{mlr --skip-comments --icsv --opprint sort -nr quantity data/budget.csv}}HERE
|
|
POKI_RUN_COMMAND{{mlr --pass-comments --icsv --opprint sort -nr quantity data/budget.csv}}HERE
|
|
|
|
</div>
|