Earlier quoted context omitted.
I don’t think the issue is that it’s hard to manually parse. The problem is that it’s hard for someone else to read your ad-hoc parser years later and reason about what you did if they need to modify it. Disclaimer: I am the author of the article and JC.
This is even more true for the ungodly long `jq` incantations that people write. It's like I get it, the old way is ugly and not always easy to decipher but at least it's shorter and your chances of understanding it are better. I've had both -- the classic piped chain of UNIX commands and various JSON-producing tools piped to `jq`. The former were still easier to work with.
Bringing the Unix philosophy to the 21st century (2019)
31–40 of 151 posts
Re: Bringing the Unix philosophy to the 21st century (2019)
#32So I've been writing shell scripts for about two decades, about 75% of that time professionally. Parsing the unstructured, text-based output of utilities is not the problem for anyone who's had maybe a few weeks of training. Most `... | grep ... | cut ... | sed ... | awk ...`-abominations the post laments can be replaced by a single informed call to `awk`, making everything a lot more elegant and concise. Having JSON…
Re: Bringing the Unix philosophy to the 21st century (2019)
#33Uh ... what about when I don't want to load the entire stream into memory before the next stage starts running? Are these implicit json arrays that stream out? Or do we now have incompatible json shell tools and streaming text tools as a permanent fixture? I'm excited about structured output ideas, but json? I'd much rather have streams of whitespace separated words than json. That's in that "No type system is better…
For the second point, whitespace sensitivity is the one mistake that greatly pisses me off with Unix. I should be able to pass arguments and filenames with as many spaces as I want. We are in the 21st century and occasionally do use spaces in filenames.
Re: Bringing the Unix philosophy to the 21st century (2019)
#34Why not go all the way and use a format capable of expressing code and data? I refer, of course, to S-expressions. They also have the benefit of properly handling numbers. Some might look at the absence of maps as a negative, but I think alists are preferable anyway due to their constant ordering.
Re: Bringing the Unix philosophy to the 21st century (2019)
#35Uh ... what about when I don't want to load the entire stream into memory before the next stage starts running? Are these implicit json arrays that stream out? Or do we now have incompatible json shell tools and streaming text tools as a permanent fixture? I'm excited about structured output ideas, but json? I'd much rather have streams of whitespace separated words than json. That's in that "No type system is better…
Re: Bringing the Unix philosophy to the 21st century (2019)
#36Uh ... what about when I don't want to load the entire stream into memory before the next stage starts running? Are these implicit json arrays that stream out? Or do we now have incompatible json shell tools and streaming text tools as a permanent fixture? I'm excited about structured output ideas, but json? I'd much rather have streams of whitespace separated words than json. That's in that "No type system is better…
That being said, I too will take a `sed` or `awk` one-liner over some of the `jq` monstrosities that I've seen.
Re: Bringing the Unix philosophy to the 21st century (2019)
#37I was literally just thinking about this a few days ago. I'm super excited by https://www.nushell.sh/ . I think they are hitting on an order of magnitude improvement paradigm of shells that fit very nicely with the theme of this article.
https://www.nushell.sh/book/ This goes against the philosophy explicitly mentioned in OP's article. E.g. avoid tabular formats. This is systemd against init again. A powerful, but overreaching shell that becomes unreplaceable and bloated with concerns. In constrast, traditional *nix/GNU programs work well, and interact well, in every shell.
I think that the shell paradigm could be so much better. If there's a momentum to make a change from that, I'll jump on the bandwagon. Any change is better than the current state of the shell.
Re: Bringing the Unix philosophy to the 21st century (2019)
#38EDIT: well, some discussion about this: https://github.com/chriskiehl/Gooey/issues/296
Re: Bringing the Unix philosophy to the 21st century (2019)
#39That `jc` command that converts non-json output to json is neat. But, um, seems slightly kludgy to be obvious. What if the `ifconfig` format changes slightly. I suppose its a stop-gap until all commands have a json output option.
$ jc -p date
jc: Error - date parser could not parse the input data. Did you use the correct parser?
For details use the -d or -dd option.Re: Bringing the Unix philosophy to the 21st century (2019)
#40That `jc` command that converts non-json output to json is neat. But, um, seems slightly kludgy to be obvious. What if the `ifconfig` format changes slightly. I suppose its a stop-gap until all commands have a json output option.
True. When I try it with `date` on Debian Sid I get parser error: $ jc -p date jc: Error - date parser could not parse the input data. Did you use the correct parser? For details use the -d or -dd option.