Timeline for Extracting a json value from bash shell using awk without having to resort to both awk and sed
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21 at 21:21 | comment | added | icarus |
@Neilski "Value" is more to type than Value. If it is worthwhile depends on what you are getting back from aws. The correct thing to do is to parse the JSON, but this is a lot of effort if you are going to restrict yourself to awk. So it is a tradeoff. We could also restrict ourselves to matching the first field. We are looking for Value but we could be looking for a.*b which is the point of my "doesn't have..." comment. So there is nothing wrong with adding the double quotes, but it probably doesn't help. Adding the colon is more problematic as it may not appear just after the quotes
|
|
| Apr 21 at 0:02 | comment | added | Neilski | @icarus Yup, my comment was focussed purely on handling the presented output from aws, but indeed for more general JSON handling you'd want to tweak it and/or accept a limited alignment with the JSON standard. However, as a bare minimum I'd suggest inclusion of the double quotation marks around Value and the colon which must come between it and the JSON 'value', no? (I'm unable to understand what you mean by '"Value" doesn't have any characters which...'; surely searching for "Value" is better than searching for Value?) | |
| Apr 20 at 14:04 | comment | added | icarus |
@Neilski It would cut down on false matches at the expense of missing correct matches. For example the whitespace can be tab characters. The question is really "what is good enough?" for a "one liner". JSON data does not be laid out one value per line, but the output from the aws command does. "Value" doesn't have any characters which have special meaning in regular expressions. We could implement a proper JSON parser in awk, and technically do it in a single (very long) line. This is the tradeoff of engineering vs mathematics.
|
|
| Apr 20 at 11:49 | comment | added | Neilski | @Kusalananda raises a valid concern. Within the constraint of not using jq, I'd personally be inclined to match the chosen line with /^ *"Value": "/ rather than just /Value/, in order to (I think) eliminate any possibility of a match with other lines of the input. | |
| Jan 22, 2020 at 17:04 | comment | added | icarus |
@Kusalananda Indeed. Using something like jq to parse the data rather than pattern match is clearly the better solution (like using sh rather than csh). The answer given is to the question as asked. I pointed out in the comments that jq would be a suitable tool, and the OP clarified that he didn't want to install any extra packages.
|
|
| Jan 22, 2020 at 16:59 | comment | added | Kusalananda♦ |
Note that if the value of e.g. Name contains the string Value, this may return unexpected data.
|
|
| Jan 22, 2020 at 16:54 | history | edited | icarus | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Jan 22, 2020 at 3:05 | vote | accept | Daniel Viglione | ||
| Jan 22, 2020 at 2:54 | history | answered | icarus | CC BY-SA 4.0 |