What I'd like is a shell that is SQL enabled.

Commands with support would detect the shell and output an SQL schema along with insert statements containing the result of the command on a special file descriptor. These would be applied to a newly created 'history#' table and aliased to the 'result' table. The standard output of the command would still be displayed as it is now.

You could then do things like 'ls' and then 'select name,size,owner from result where size > 1024 and owner != 0;' And continue to run queries against the last result until it's replaced by a new command. Or run queries against the 'history#' table or multiple tables to join results from multiple independent commands.

With support for JSONB in most SQL engines this would provide a nice mechanism for working with any sort of nested data structure from any given program or from plain JSON files if required.

No contraversial at all. And without sounding like I'm flogging a dead horse, since I've mentioned it elsewhere, but you're after Nushell. Everything is data, structured data. And of interest to a sibling comment it's syntax is similar to SQL, with things like where and select.

Edit: in relation to the other sibling comment, Nushell was developed as an improvement over powershell. I use both and prefer nushell's syntax.

Agreed. My personal hot take is that powershell is a great way to deal with json.

Well you see, the author already knows common lisp, is familiar with their own ad hoc DSL by virtue of having just come up with it, and refuses to learn jq.

Personally, I probably would've written '[.root[][1]]' for that problem myself though—not a huge fan of map/1.

Just noticed this was submitted here.

1) I dislike that .[1] can be both an expression evaluated as a query and a "lambda". Really messes with my mind.

2) In my eyes, it's more intuitive because it looks like globbing and everybody knows globbing (this is the reason I use `**` too).

But yeah, this is a bit subjective. What isn't, though, is that I don't plan on adding much more than that; maybe merge, transform and an accessor using the same syntax. So if you know the host language, there's much less friction.

I really see this like Avisynth vs Vapoursynth.

site looks like a bashcompletion thing, how does it replace jq?

There's a few jq patterns I've adopted:

   echo "$SOME_JSON" | jq '.[]' --raw-output --compact-output | while read -r LINE ; do ... ; done

...lets you process stuff "record by record" pretty consistently. (and `( xxx ; yyy ; zzz ) | jq --slurp '.'` lets you do the reverse, "absorbing" multiple records into an array.

Don't forget `--argjson`

    echo "{}" | jq --argjson FOO "$( cat test.json )" '{ bar: $FOO }'

...lets you "load" json for merging, processing, formatting, etc. The leading "{}" is moderately necessary because `jq` technically _processes_ json, not generates it.

Finally, it's a huge cheat code for string formatting!!

     $ echo "{}" | jq \
        --arg FOO "hello \$world" \
        --arg BAR "complicated \| chars" \
        --arg ONE 1 \
        --arg TWO 2 \
        '"aaa \( $FOO ) and \( $BAR ) and \( ($ONE | tonumber) + ($TWO | tonumber) ) bbb"'
     "aaa hello $world and complicated \\| chars and 3  bbb"

...optionally with `--raw-output` (un-json-quoted), and even supports some regex substitution in strings via `... | gsub(...)`.

Yes, yes... it's overly complicated compared to you and your fancy "programming languages", but sometimes with shell stuff, the ability to _CAPTURE_ arbitrary command output (eg: `--argjson LS_OUTPUT="$( ls -lart ... )"`), but then also use JSON/jq to _safely_ marshal/deaden the data into JSON is really helpful!

It's even included in macOS now (as of Sequoia).

Also lqn/jqn

https://github.com/inconvergent/lqn

>(safety 0)

Please, don't do that!

This is a bit of a nonsense benchmark—the author is basically benchmarking process startup time, and finding that if you only start one lisp process, it runs faster than if you start one jq process per input file, which runs faster than if you start one lisp process per input file. This becomes quite clear at the end when they compare multiple jq implementation (which are known to have nontrivially different parsing performance characteristics, which is the bulk of the "real work" for this task lies) and come up with execution times on the same order of magnitude.

A more apples-to-apples comparison would be to use find {} + to pass multiple filenames to jq and output using input_filename.

If you want it in your actual preferred language, it's usually pretty easy to throw something together.

E.g. Ruby:

    require 'json'
    script = ARGV.pop
    $J = JSON.parse(ARGF.read)
    puts JSON.pretty_generate(eval(script))

Lets you do:

curl --silent https://api.vultr.com/v2/regions | ./jr '$J["regions" ].find{_1["id"]=="nrt"}'

To translate their example ( curl --silent https://api.vultr.com/v2/regions | rcl query input.regions.key_by(r => r.id).nrt )

(... if you want to commit evil monkey-patching sins:

    #!/usr/bin/env ruby

    require 'json'
    
    class Hash
      def method_missing(sym) = (((r = self.dig(sym.to_s)) and return r) or super)
    end

    script = ARGV.pop
    $J = JSON.parse(ARGF.read)
    script = "$J#{script}" if script.start_with?(".")
    puts JSON.pretty_generate(eval(script))

Now you can do:

   curl --silent https://api.vultr.com/v2/regions | ./jr '.regions.find{_1.id =="nrt"}'

Or the more direct parallel:

   curl --silent https://api.vultr.com/v2/regions | ./jr '.regions.group_by{_1.id}.nrt'

Since I used ARGF, you either need to quote the script or avoid spaces; you could explicitly use STDIN instead, in which case it's marginally safer to skip the quotes, at the cost of not being able to give a filename as the last argument

)

It feels like we're in danger of being stuck with the popular tools we have now for the foreseeable future. Why use a new tool when you can have the LLM figure it out using the old tools? Which means LLMs can't learn new tools because there's no human examples for them to learn from.

It's definitely rocking that Common Desktop Environment style https://en.m.wikipedia.org/wiki/Common_Desktop_Environment

For those that like that style, on Linux both Xfce and KDE have themes that replicate it for their window decorations (recommending the desktop environment would be a bit too much)

He's got an "about..." section which is a treat and gives some details on it. It works surprisingly well and is a bit of a blast from the past! :-D

no, what the author claims is that jq should've been designed as a regular python library, using python syntax, rather than as a bespoke DSL (that happens to have parser bindings for python)