Which format to use a as representation of data structure might be debatable, but I think JSON is a reasonable choice. (Formatted) JSON is readable by human and could be easily parsed by programs.
Bringing the Unix philosophy to the 21st century (2019)
41–50 of 151 posts
Re: Bringing the Unix philosophy to the 21st century (2019)
#42Why 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)
#43That `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.
Re: Bringing the Unix philosophy to the 21st century (2019)
#44That `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.
If the ifconfig output changes slightly, then it will probably break the thousands of ad-hoc parser implementations buried in scripts worldwide. With this approach, only a central parser library (open source) needs to be maintained so it can be fixed quickly and robustly. That being said, the goal is that command line tools that output useful data for scripts should have a structured output option like JSON while sti…
Re: Bringing the Unix philosophy to the 21st century (2019)
#45I can understand why the idea of more structured, object-like input and output is appealing, but after using PowerShell for a while, my take is that it's much harder to manipulate objects into a consistent format than it is to manipulate text. For instance, if you want to compare Azure DNS records with DNS records from a Windows server, it's a huge pain because Get-AzDnsRecordSet and Get-DnsServerResourceRecord retur…
You can always just thunk down to the text representation and do things that way. Having the structure is a strict plus, no?
Mandating tab separated columns with a consistent quoting for embedded spaces would be a net benefit. And it would match today's tools well.
Re: Bringing the Unix philosophy to the 21st century (2019)
#46So 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)
#47So 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…
What i would like is an cli awk ide. (Rolls of the tongue right? )
Ideally i could write ... | awk-ide "scripts/thing.awk" | ...
If it exists, run it. Otherwise have it open an editor session that runs an awk program as i type it on some buffered data, shows the result, and have some hints on what syntax/variables are available.
Re: Bringing the Unix philosophy to the 21st century (2019)
#48Why 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)
#49Why 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.
To put it in 2021 terms, Jupiter Netbooks in 1980's instead of PDP-11 green phosphor terminals.
Re: Bringing the Unix philosophy to the 21st century (2019)
#50So I have to bring in jsmn.h to parse protocols? Sorry no. Been there, done that. We are pushing too much unnecessary JSON around already.
Unix is also about KISS. Structured data are lines and paragraphs.