Take your README examples:
-- flite
SELECT * FROM lines("/path/to/some/file.ndjson")
# murex
open /path/to/some/file.ndjson | select *
. -- flite
SELECT readfile("/path/to/file.json")
# murex
open /path/to/file.json | select *
. -- flite
SELECT yaml_to_json("hello: world")
# murex
tout yaml "hello: world" | format json
. -- flite
SELECT json_to_yaml('{"hello":"world"}')
# murex
tout json {"hello":"world"} | format yaml
What's happening here is the pipes are typed (rather than dumb byte streams) so subsequent commands, if they support _murex_ pipes as opposed to dumb POSIX pipes, are able to take advantage of a multitude of different marshallers without each command needing to worry the underlying file format of the content.`open`, as you might expect, opens the file and pushes the content to STDOUT. It's a little bit like `cat` except it pushes data type information down the pipe. It also differs a little from cat in that it can render different output depending on whether STDOUT is a TTY or a pipe. eg JSON can be formatted for human readability if it's a TTY or minimised for bandwidth if it's a pipe. The shell gets a little bit more clever here though in that images are rendered to the terminal if STDOUT is a TTY but pushed as a byte stream if it's a pipe. https://murex.rocks/docs/commands/open.html
`tout` is `typed output`. So you're saying "echo this output and set the data type to ..." https://murex.rocks/docs/commands/tout.html
`select` is the sqlite3 connector https://murex.rocks/docs/optional/select.html
`format`, as you might have guessed, is for changing the data type and data format (you can change the data type without the format by using `cast`). https://murex.rocks/docs/commands/format.html
---
Looking through your code, it's pretty cool what you've written too. Also loving the clean readable code. Good work there.