Thanks Alex, I am not so concerned by number being the day of the week since the assumption is that there is an implicit understanding of all the "types" in the consuming code - I mean, it will be understood that all the numbers need to be either used in mathematical expression or divided by the scale if it is consumed directly. The sed solution has the risk of altering strings that are unintended - I can change it a bit to make it a little more robust - also I have to do it twice since the first substitution may add .0 to numbers that are already floats.
sed -r 's/(:\s+)([0-9.]+)\b/\1\2.0/g' | sed -r 's/(:\s+)([0-9]+)\.([0-9]+)\.0/\1\2.\3/g' But I see your point. Would it be reasonable to temporarily override "read" to read number differently? or is that an overkill? regards, Kashyap On Mon, May 6, 2019 at 10:44 AM Alexander Burger <a...@software-lab.de> wrote: > On Mon, May 06, 2019 at 07:22:05AM -0700, C K Kashyap wrote: > > I'm afraid, the generating side is outside my control :( - I am looking > at > > this - https://api.iextrading.com/1.0/stock/aapl/chart/3m > > There is a way, I do this usually by reading from a pipe and modify the > data > along the way as necessary. > > Basically you can read this as > > (in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";) > (readJson) ) > > Now you can do modifications here, either by calling a script with 'curl' > and > some filtering with 'sed' or 'awk, or do it directly: > > (in '("sh" "-c" "curl -s > https://api.iextrading.com/1.0/stock/aapl/chart/3m | sed 's/xxx/yyy/g") > (readJson) ) > > > > In this case, scaling everything does not seem so bad - infact, the > > solution i was trying was to simply add a ".0" to all the numbers that > did > > not have it. > > Yes, can be done with the above 'sed'. > > But only if you are sure that none of the numbers is meant to be a plain > integer. > > > > Also, would it not be okay to say that all the numbers in the JSON (or > some > > other input) are scaled? It's for the user to be aware and deal with it > > appropriately. > > Not in the general case. Imagine there is a number "7" in the data meaning > a day > of the week or whatever. It would end up as 700 :) > > ☺/ A!ex > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
