Parsing numbers

[kellyjonbrazil]

Parsing numbers

[kellyjonbrazil]

Yeah, good idea, I was thinking similar after I responded. I could leave the string representation and add fields for the number representation (eg. size_num). X_num fields, if they exist, would be the int/float version if the regular field contains only digits and a ‘.’. Something like that. Btw, I’m working on an improved netstat implementation. Kelly Brazil [phone] Sent from my mobile device

…

On Nov 2, 2019, at 10:08 AM, Ilya Sher ***@***.***> wrote:  Suggested alternative: have a "schema" and now where the numbers supposed to be. If the user chooses -h for "human" output and then uses jc for machine parse-able that's an error (exception). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ilyash-b]

would eliminate |tonumber in jq I guess

From readme:

ls -l /usr/bin | jc --ls | jq '.[] | select(.size|tonumber > 50000000)'

[kellyjonbrazil]

I originally was converting numbers to int or float but then I found that if the user chooses -h for human readable format then it made things more complicated to correctly parse. So then I figured it would be best to keep everything a string representation and leave the conversion to the user downstream. Maybe I could add a flag that allows the user to choose to have the parser to keep numbers? Kelly Brazil [phone] Sent from my mobile device

…

On Nov 2, 2019, at 9:42 AM, Ilya Sher ***@***.***> wrote:  would eliminate |tonumber in jq I guess From readme: ls -l /usr/bin | jc --ls | jq '.[] | select(.size|tonumber > 50000000)' — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ilyash-b]

Suggested alternative: have a "schema" and now where the numbers supposed to be. If the user chooses -h for "human" output and then uses jc for machine parse-able that's an error (exception).

[ilyash-b]

I was thinking about stricter behaviour: you know where the numbers need to be. If the input is not a number, it's probably because of -h and jc probably should not parse anything like that because it's kind of sabotage by the user: runs the command explicitly requesting human output and makes jc parse it

[kellyjonbrazil]

I think i'd like to keep the original representation, too, for other use cases. Since it's easy to add fields to json that can be ignored if not needed I don't mind making extra _num_x or whatever fields to convert known numbers to number format if they are parsable.

[kellyjonbrazil]

Or actually, the opposite way so you can use the results more easily in your application.

Be strict in parsing, but if -h type of input is found and not parsable as a number, add a _fieldname with the non-parsable text output and you can just ignore the _fieldname fields if you just care about machine parsable data?

[kellyjonbrazil]

Was thinking about this a bit more and I think it makes more sense to provide the existing output when the user passes a -r or raw=true flag. The default output would be a strict schema representation with additional semantic information.

This allows for both use cases where you can use jc as a layer higher than sed/awk/grep but can also use it for higher level presentation.

I’ll start working on this. This solves the conflict I ran into in the earlier versions and I think it will be good for your project.

[ilyash-b]

The default output would be a strict schema representation with additional semantic information.

Sounds good!

[kellyjonbrazil]

Hi Ilya,

I have incorporated your suggestions into the dev branch. I'm still working on some fixes and documentation, but it's pretty close to being merged in the next week or two.

Feel free to test/provide feedback on the dev branch:

pip3 uninstall jc
git clone --single-branch --branch dev https://github.com/kellyjonbrazil/jc.git
cd jc
./install.sh

[ilyash-b]

Hi. Not getting to it. I'll take a look later.

[kellyjonbrazil]

updates in master version 1.5.1, also via pip3

[kellyjonbrazil]

BT2|~SktOUkc1TUhETjR8fktlbGx5fH45Nzg0NA== Kelly Brazil [phone] Sent from my mobile device