Hacker News new | past | comments | ask | show | jobs | submit login

There are at least 3 ways this can create bugs:

  - It has to parse output of commands which may or may not be intended to be parsed and may or may not have a predictable format. The only way to overcome this is if this program becomes one of the Big Four "UN*X command output -> data" converters

  - It casts things to "float/int"

  - Depending on who made this library, the output itself may not be strict / predictable. Perhaps it will output JSON with two different key names in two different scenarios.
And don't forget that any of these issues will still come up even if they are accommodated for, due to versions of programs changing without the author of this tool knowing.

But yeah basic things having intrinsic shortcomings is a given, when you're using UN*X.

From the nested article:

> Had JSON been around when I was born in the 1970’s Ken Thompson and Dennis Ritchie may very well have embraced it as a recommended output format to help programs “do one thing well” in a pipeline.

They had S-expressions and plenty more options. They also could have just made a format as you can tell with thousands of ad-hoc trendy new formats like YAML and TOML being spewed out every recent year now that programmers discovered data structures.




Hi - jc author here. Just a couple points:

The casting to int/float is not done unless the underlying values are predictably documented to be numbers. There are rare cases where auto int/float conversions are done, but:

1) This is always documented, and

2) You can turn this functionality off via the —raw flag

Also, predictable schemas are documented with each parser. (e.g `jc -h —-arp`)


> Big Four "UN*X command output -> data" converters

What do you mean?


I mean that there would be a big 4 such converters if people actually invested time into these "front ends" to CLIs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: