> That shell also sends metadata about the documents being piped which means
  > you effectively have typed pipes (like Powershell but backwards compatible
  > with POSIX tools). So it means you can do more with the table afterwards too.

It looks like such a shell would greatly benefit from a stdmeta file descriptor, as described here:

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

The idea is that such a file descriptor would output lines that are not part of the data yet are not errors. One example usage would be to output the headers of commands such as ps, and murex could use such stdmeta lines as column names.

That would be awesome but I think what we need is something a little more programmatic. eg a standard way of passing Content-Type / MIMEs with fields for meta-data. A hypothetical example might look like this:

  {
    "Content-Type": "application/table",
    "Stdin": "ls",
    "Meta": {
      "Columns": [ "filename", "date", "permissions", "owner" ]
    }
  }

I'm not suggesting that data should be JSON formatted though. Nor even have fields identical to the above. But a standard agreed base so that applications can understand what the pipe is without the developers having to write a thousand different case statements for each different stdmeta content but while still allowing some enhanced functionality for common commands.

In an idea world this would be an API rather than file descriptor but that would be backwards incompatible and even the FD use case feels like nice thing that is always going to be out of reach. :(

Thanks for sharing that by the way. I hadn't seen that post before.