3 ms·

There are many downsides. There are problems with using JSON for this; other formats would be better. JSON needs escaping, cannot effectively transfer binary d

There are many downsides. There are problems with using JSON for this; other formats would be better. JSON needs escaping, cannot effectively transfer binary data (other than encoding as hex or base64), cannot use character sets other than Unicode, etc. People think JSON is good, but it isn't. Also, you might want to use less or other programs for the text output, which might be the primary output that you might also want to pipe to other programs, redirect to a file (or printer), etc. This text might be separate from the status messages (which would be sent to stderr; these status messages are not necessarily errors, although they might be). If you use --help deliberately then the help message is the primary message, not a status message. (In a new operating system design it could be improved, but even then, JSON is not the format for this; a binary format would be better (possibly DER, or SDSER, which is a variant of DER that supports streaming, in a (in my opinion) better way than CER and BER does).) (Another possibility might be to add another file descriptor for structured data, and then use an environment variable to indicate its presence. However, this just adds to the messiness of it a little bit, and requires a bit more work to use it with the standard command shells.)

vacuity 11mo ago
I think standardizing a file descriptor interface would be ideal. It's ridiculous that the file descriptors are exposed and densely packed. I wonder if a protocol could be made that demultiplexes for stderr and the new file descriptor could be made.
- zzo38computer 11mo ago
  I do not understand very well what you mean.
  - vacuity 11mo ago
    I'd like to make another standard file descriptor to manage the control plane, like stdin/stdout/stderr, but figuring out which file descriptor it should be is a bit complicated. I'm wondering if the OS could backwards-compatibly integrate it with stderr in the standard file descriptor at index 2.
    - zzo38computer 11mo ago
      OK, but I don't know how you would integrate it with an existing file descriptor. (It is why I suggested using a environment variable to manage this.)
    - skissane 11mo ago
      Historically some systems did have more than three standard file descriptors - e.g. for MS-DOS C compilers, a de facto standard was stdprn was your printer and stdaux was a serial port - this was because while Unix by default starts each process with 3 inherited handles, MS-DOS has 5 (CP/M influence). NT-based Windows abandoned this But trying to add a fourth now, would likely break too many things; some software will assume any fd > 2 is free for it to clobber. The IBM mainframe operating system z/OS (formerly MVS), classically instead of numbers for inherited descriptors, the API uses names (DDNAMEs)-that would have made adding a new one a lot easier. But decades too late for that in Unix land, and eventually MVS added the Unix way too for Unix compatibility-the classic API still uses DDNAMEs, but many apps now use the file descriptor-based z/OS Unix API instead
    - 1718627440 11mo ago
      You can open another file descriptor at any time and some programs allow you to specify a file descriptor instead of the filename.
robot-wrangler 11mo ago
I guess I don't see those as big downsides because I don't think people usually want binary data or quoted strings back from a CLI command, nor do they want column oriented output, nor "user friendly" tables. Answering --help with JSON is a good example, how bad is it really if the response is JSON? Well, using less works fine still and you can still grep if you want simple substring search. Wanting a section is probably more common, so maybe you'd "grep" for a subcommand with `jq .subcommand` or an option with `jq .subcommand.option`, and maybe get yourself a fancier, JSON-friendly version of less that handles escaped quotes and newlines. Tables and tab-or-space delimited output overflow char limits, force the command-generator to figure out character wrapping, and so on. Now you need a library to generate CLI help properly, but if you're going to have a library why not just spit JSON and decouple completely from display details to let the consumer handle it. Structured output by default just makes sense for practically everything except `cat`. And while your markdown files or csv files might have quoted strings, looking at the raw files isn't something people really want from shells or editors.. they want something "rendered" in one way or another, for example with syntax highlighting. Basically in 2025 neither humans nor machines benefit much from unstructured raw output. Almost any CLI that does this needs to be paired with a parser (like https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc) and/or a renderer (like https://github.com/charmbracelet/glow https://github.com/charmbracelet/glow). If no such pairing is available then it pushes many people to separately reinvent parsers badly. JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML
- zzo38computer 11mo ago
  Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML). > JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)

vacuity 11mo ago

I think standardizing a file descriptor interface would be ideal. It's ridiculous that the file descriptors are exposed and densely packed. I wonder if a protocol could be made that demultiplexes for stderr and the new file descriptor could be made.

zzo38computer 11mo ago
I do not understand very well what you mean.
- vacuity 11mo ago
  I'd like to make another standard file descriptor to manage the control plane, like stdin/stdout/stderr, but figuring out which file descriptor it should be is a bit complicated. I'm wondering if the OS could backwards-compatibly integrate it with stderr in the standard file descriptor at index 2.
  - zzo38computer 11mo ago
    OK, but I don't know how you would integrate it with an existing file descriptor. (It is why I suggested using a environment variable to manage this.)
  - skissane 11mo ago
    Historically some systems did have more than three standard file descriptors - e.g. for MS-DOS C compilers, a de facto standard was stdprn was your printer and stdaux was a serial port - this was because while Unix by default starts each process with 3 inherited handles, MS-DOS has 5 (CP/M influence). NT-based Windows abandoned this But trying to add a fourth now, would likely break too many things; some software will assume any fd > 2 is free for it to clobber. The IBM mainframe operating system z/OS (formerly MVS), classically instead of numbers for inherited descriptors, the API uses names (DDNAMEs)-that would have made adding a new one a lot easier. But decades too late for that in Unix land, and eventually MVS added the Unix way too for Unix compatibility-the classic API still uses DDNAMEs, but many apps now use the file descriptor-based z/OS Unix API instead
  - 1718627440 11mo ago
    You can open another file descriptor at any time and some programs allow you to specify a file descriptor instead of the filename.

robot-wrangler 11mo ago

I guess I don't see those as big downsides because I don't think people usually want binary data or quoted strings back from a CLI command, nor do they want column oriented output, nor "user friendly" tables. Answering --help with JSON is a good example, how bad is it really if the response is JSON? Well, using less works fine still and you can still grep if you want simple substring search. Wanting a section is probably more common, so maybe you'd "grep" for a subcommand with `jq .subcommand` or an option with `jq .subcommand.option`, and maybe get yourself a fancier, JSON-friendly version of less that handles escaped quotes and newlines. Tables and tab-or-space delimited output overflow char limits, force the command-generator to figure out character wrapping, and so on. Now you need a library to generate CLI help properly, but if you're going to have a library why not just spit JSON and decouple completely from display details to let the consumer handle it. Structured output by default just makes sense for practically everything except `cat`. And while your markdown files or csv files might have quoted strings, looking at the raw files isn't something people really want from shells or editors.. they want something "rendered" in one way or another, for example with syntax highlighting. Basically in 2025 neither humans nor machines benefit much from unstructured raw output. Almost any CLI that does this needs to be paired with a parser (like https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc) and/or a renderer (like https://github.com/charmbracelet/glow https://github.com/charmbracelet/glow). If no such pairing is available then it pushes many people to separately reinvent parsers badly. JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML

zzo38computer 11mo ago
Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML). > JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)