5 ms·

My one wish for UNIX coreutils would be that they all had a switch to output JSON. ls --json ps aux --json If they did that, all that powershell stuff would

My one wish for UNIX coreutils would be that they all had a switch to output JSON. ls --json ps aux --json If they did that, all that powershell stuff would become trivial. Wouldn't even be hard.

bishop_mandible 11y ago
Why not TOML?
- hk__2 11y ago
  JSON is a standardized format, TOML is not.
Comaleaf 11y ago
How would that work for late-evaluated data? A PowerShell object doesn't have to provide all of the data up-front, and can give updated data when checked at a later date. JSON is still just text, it still needs to provide all of the data you might need up front.
- jsjohnst 11y ago
  Great point that I think all the JSON advocates are missing.
  - rlguarino 11y ago
    Text streams also have that problem.
    - jsjohnst 11y ago
      Not necessarily. Text streams don't have to by default provide all possible data for the next process in the pipe. Sure, you could keep all the command line arguments you had before to make JSON output manageable, but then you have two problems rather than one.
oinksoft 11y ago
Ten years ago this would be --xml. Who knows what it would be ten years from now. Text streams are timeless.
- crdoconnor 11y ago
  XML is a mess and it was no less of a mess 10 years ago. Text streams are unstructured, so parsing them is a pain in the ass. JSON is simple, standardized, and not going anywhere.
- alkonaut 11y ago
  Text streams are just an ad hoc structured format. Even an out of date format is better than one you have to invent or decode on a per case basis. The whole xml vs json debate feels pretty pointless, they are for all practical purposes equal (in size, complexity etc). Sure xml has some weird design decisions around namespaces and so on, but if you use it as a simple hierarchical markup it's pretty much equivalent to json with different brackets? and often easier to parse for humans because of closing tags instead of }}} and of course, comments. The xml-hate I think isn't really xml-hate it's the reaction against the xml-y things from 10-15 years ago: the IBM/Struts/Blah we all had to wade through. These days it feels frameworks pick json over xml even when it's clearly an inferior choice (such as for config files). Json is an object/message markup, not a good human readable config format.
  - crdoconnor 11y ago
    XML hugely complex and difficult to parse despite not being any more useful than JSON as a means of representing or transmitting data. YAML is a far superior format to XML for config files, and is basically JSON in a readable format. There's literally zero reasons to choose to use XML where you could use JSON/YAML instead.
    - vezzy-fnord 11y ago
      YAML may look quite simple on the outside, but the specification of it is surprisingly complicated.
pronoiac 11y ago
Hey, would that be easier if we rewrite the coreutils in, say, Rust? Honest question.
- agumonkey 11y ago
  Efforts have been done, see: https://github.com/uutils/coreutils https://github.com/uutils/coreutils https://www.google.com/search?q=coreutils+rust https://www.google.com/search?q=coreutils+rust
_paulc 11y ago
See libxo[1] There has been added in FreeBSD 11 but I am not sure how many of the commands have been converted. [1] https://juniper.github.io/libxo/libxo-manual.html https://juniper.github.io/libxo/libxo-manual.html
- McElroy 11y ago
  >I am not sure how many of the commands have been converted There's a page [1] on the FreeBSD wiki with a list of converted and ongoing conversion. I don't know if the list is complete but the page was last modified 2015-05-22, so it should be fairly up to date i guess. [1]: https://wiki.freebsd.org/LibXo https://wiki.freebsd.org/LibXo
jsjohnst 11y ago
Except how do you represent every possible data type without losing fidelity? I made this point in another leaf, but it's worth echoing again. A perfect example of this is Dates. There isn't a defined JSON type for that so we'd be back to basic text parsing again (which will cause anyone who has dealt with parsing dates to recoil in agony). When you try to ram a one size fits all approach to everything, you end up with abominations like SOAP with XML. I simply don't get the fascination with trying to use the same tool for every job even if it's not applicable.

My one wish for UNIX coreutils would be that they all had a switch to output JSON. ls --json ps aux --json If they did that, all that powershell stuff would become trivial. Wouldn't even be hard.

bishop_mandible 11y ago

Why not TOML?

hk__2 11y ago
JSON is a standardized format, TOML is not.

Comaleaf 11y ago

How would that work for late-evaluated data? A PowerShell object doesn't have to provide all of the data up-front, and can give updated data when checked at a later date. JSON is still just text, it still needs to provide all of the data you might need up front.

jsjohnst 11y ago
Great point that I think all the JSON advocates are missing.
- rlguarino 11y ago
  Text streams also have that problem.
  - jsjohnst 11y ago
    Not necessarily. Text streams don't have to by default provide all possible data for the next process in the pipe. Sure, you could keep all the command line arguments you had before to make JSON output manageable, but then you have two problems rather than one.

oinksoft 11y ago

Ten years ago this would be --xml. Who knows what it would be ten years from now. Text streams are timeless.

crdoconnor 11y ago
XML is a mess and it was no less of a mess 10 years ago. Text streams are unstructured, so parsing them is a pain in the ass. JSON is simple, standardized, and not going anywhere.
alkonaut 11y ago
Text streams are just an ad hoc structured format. Even an out of date format is better than one you have to invent or decode on a per case basis. The whole xml vs json debate feels pretty pointless, they are for all practical purposes equal (in size, complexity etc). Sure xml has some weird design decisions around namespaces and so on, but if you use it as a simple hierarchical markup it's pretty much equivalent to json with different brackets? and often easier to parse for humans because of closing tags instead of }}} and of course, comments. The xml-hate I think isn't really xml-hate it's the reaction against the xml-y things from 10-15 years ago: the IBM/Struts/Blah we all had to wade through. These days it feels frameworks pick json over xml even when it's clearly an inferior choice (such as for config files). Json is an object/message markup, not a good human readable config format.
- crdoconnor 11y ago
  XML hugely complex and difficult to parse despite not being any more useful than JSON as a means of representing or transmitting data. YAML is a far superior format to XML for config files, and is basically JSON in a readable format. There's literally zero reasons to choose to use XML where you could use JSON/YAML instead.
  - vezzy-fnord 11y ago
    YAML may look quite simple on the outside, but the specification of it is surprisingly complicated.

pronoiac 11y ago

Hey, would that be easier if we rewrite the coreutils in, say, Rust? Honest question.

agumonkey 11y ago
Efforts have been done, see: https://github.com/uutils/coreutils https://github.com/uutils/coreutils https://www.google.com/search?q=coreutils+rust https://www.google.com/search?q=coreutils+rust

_paulc 11y ago

See libxo[1] There has been added in FreeBSD 11 but I am not sure how many of the commands have been converted. [1] https://juniper.github.io/libxo/libxo-manual.html https://juniper.github.io/libxo/libxo-manual.html

McElroy 11y ago
>I am not sure how many of the commands have been converted There's a page [1] on the FreeBSD wiki with a list of converted and ongoing conversion. I don't know if the list is complete but the page was last modified 2015-05-22, so it should be fairly up to date i guess. [1]: https://wiki.freebsd.org/LibXo https://wiki.freebsd.org/LibXo

jsjohnst 11y ago

Except how do you represent every possible data type without losing fidelity? I made this point in another leaf, but it's worth echoing again. A perfect example of this is Dates. There isn't a defined JSON type for that so we'd be back to basic text parsing again (which will cause anyone who has dealt with parsing dates to recoil in agony). When you try to ram a one size fits all approach to everything, you end up with abominations like SOAP with XML. I simply don't get the fascination with trying to use the same tool for every job even if it's not applicable.