Hacker News Reader

Comment by scj | Hacker News Reader

I've always wondered about expanding stdin, stdout, stderr. Say, stdjson that doesn't get visually displayed, but can be piped (and would only be generated if it is needed on the pipe stream).

ls | cat </dev/stdjson | string_proc_the_json_for_some_reason

With the direct ability to process in line:

ls -a | json.files[0].last_modified

I'd probably want multiple output formats (including s-expressions).

View on HN

You seem to be pretty close to Nushell, which was mentioned in the article. The Nushell `ls` (and `ps`, etc.) builtins generate structured data that can be sorted, queried, reduced, and then transformed to many different types of structured data.

$ ls | get 0 | select modified | to json

{ "modified": "2022-08-16 16:38:28 -04:00" }

The internal data format looks pretty JSON-like, with the added ability to keep Nushell types intact.

While I'm not ready to replace Fish with Nushell, it's definitely taken the place of jq for me.

I dream of stdmeta for e.g. header lines:

https://unix.stackexchange.com/questions/197809/propose-addi...

I see much potential in adding stdjson as well, but I do caution against opening the floodgates to std* being implemented for every pet format and insignificant corner case.

It sounds like you either want powershell or FreeBSD's libxo?

What about an ioctl that lets you query what formats are accepted by the file descriptor? We already sort of have a precedent for it with giving different output based on isatty().

(fully daydreaming here) For C, would it be useful to have main() look like:

   int main(int argc, char *argv[], char *envp[], JSON *json)

for some JSON data type that is part of C, kind of analogous to a FILE stream? I'm not sure how the the json info would get into that fourth argument (has to be independent of argv), but it would keep std{in,out,err} as is.

You would need to modify the execve system call (or equivalent non-Linux OS's) to take in the 4th json arg for the shell to pass when it exec's the new process. And then of course modify the OS kernel to parse/deal with it. But in reality, since you can't break the ABI like that for all existing software, it would end up being execve_2 or something and you'd have to both convince everyone else it's worth using, and deal with the inevitable incompatibilities when not everyone does. Not impossible perhaps, but certainly an uphill battle.

You can always just use JQ.

Additionally, as JSON is text, you can use awk/sed/grep and so on.

The intent is that standard tools would output alternative formats.

Right; every file is just bytes but we get a lot of mileage out of libraries like libpng that parse those bytes into usefully structured info. And I was pondering what more could evolve to parse info from the command line.

I think stdjson is insane yet awesome to ponder.

I agree that a standardized structured format would be awesome, but I'm not convinced that JSON is it. And there should _not_ be more than one.

One thing that I do like about JSON is that it is ubiquitous - and that makes up for a lot of its other faults. But I would like to see proposed use cases that JSON would not support beforehand, to clearly define where the limitations are, and what limitations the community is willing to accept.

The tool should instead provide an `--output=<format>` flag, where <format> is one of text (default), json, xml, etc.

Reply on news.ycombinator.com