Operating system code test request...

[jacque]

I should mention that LC always uses LF internally. The different line endings are applied when exporting text, and retained when importing text as binary. Importing text as plain text causes LC to convert native line endings to LF.

[bogs]

Yah, that was what I didn't get. I figured if you handled the text within Lc, without saving it to file, it would automatically format it the same way and save it out as whatever the OS your using used, apparently that isn't the case though?

On lin , that information comes out line specific using curl (you get the json format), so I'm wondering if you are using the api line that SparkOut mentioned, or the /json line Richard posted?

SparkOut's [put url ("http://api.infoip.io/")] returns a single line in a json / csv format...


Richard's [put url "http://ipinfo.io/json"] returns a line delimited json format....


I'm not sure either is shorter or more simple than the other heh, so which return you'd want I guess would be a matter of preference. I'm pretty sure either should work on mobile, or at least, I can't see why one wouldn't over the other.

Interesting tidbit, I found out there is no equivalent to curl on Win. Go figure. There *is* a kind of thing you could use, but apparently it is a tad leaky (it keeps connections open) <sigh>.

[FourthWorld]

Unlike YAML, JSON has no semantic role for white space, and so any white space characters are best regarded as subject to change at any time.

The way to parse JSON robustly is with a dedicated JSON parser, like the included JSONtoArray.

[SparkOut]

FYI, on Windows here with 9.6.2 the http://ipinfo.io/json form gives me a rendition of the page source, and not the ip geo lookup.

[kdjanz]

Code: Select all

{
  "ip": "104.246.xxx.xxx",
  "hostname": "104-246-xxx-xxx.cpe.teksavvy.com",
  "city": "Edmonton",
  "region": "Alberta",
  "country": "CA",
  "loc": "53.5501,-113.4687",
  "org": "AS5645 TekSavvy Solutions, Inc.",
  "postal": "T5H",
  "timezone": "America/Edmonton",
  "readme": "https://ipinfo.io/missingauth"
}

Here is what I get using the http://ipinfo.io/json form. I am actually about 50 km from the location given, and the gps coordinates put me in the middle of a fairly big river around here.

[bogs]

Here is what I get using the http://ipinfo.io/json form. I am actually about 50 km from the location given, and the gps coordinates put me in the middle of a fairly big river around here.

Thanks for testing it, 50 km is accurate enough for the purposes of this program

FYI, on Windows here with 9.6.2 the http://ipinfo.io/json form gives me a rendition of the page source, and not the ip geo lookup.

That is pretty wierd, I tested it with 8.1.8 on XP, and got what I was looking for.

Unlike YAML, JSON has no semantic role for white space, and so any white space characters are best regarded as subject to change at any time.

The way to parse JSON robustly is with a dedicated JSON parser, like the included JSONtoArray.

I defer to your far greater experience in this arena, but for the 2 bits of information I need from what is returned, word and or lineOffset works fine. I'm actually sticking with lineOffset for now, and using the colon as the item delimiter. I need to pad the returned lat. / long. with zeroes anyway for the info from NOAA.

[SparkOut]

I tried again and with judicious use of waits and wrapping URL in brackets I got results from both the ipinfo.io/json url and api.ipinfo.io url, with wildly different (but consistent) results.
Loughborough is about 400 miles drive from here, returned with the json version. The api.ipinfo.io result is pretty close, the marker pin for that lat/long drops about 10 miles away.

[FourthWorld]

FYI, on Windows here with 9.6.2 the http://ipinfo.io/json form gives me a rendition of the page source, and not the ip geo lookup.

A "rendition"?

Which browser?

What do you get if you use LC?

[bogs]

I tried again and with judicious use of waits and wrapping URL in brackets...

I'm not sure why you would have to wait or wrap anything in brackets, wierd. I just tested it in 9.6.2 here on 'nix, I get exactly what has been shown repeatedly throughout this thread.

I don't have a win10 box to test on anymore, so maybe I'll put a disclaimer on it that Windows results may be "iffy" hee hee.

[FourthWorld]

...for the 2 bits of information I need from what is returned, word and or lineOffset works fine...

...today. And depending on what the client software expects a "line" to be.

And maybe it'll work tomorrow.

But since JSONtoArray is a one-liner it seems an easy way to rest well.

[SparkOut]

That ("rendition") was using LC to get that url, and the value return in "it" was the page source code.

I have since got the actual data returned (needing a wait before getting the url, ugh...) but as noted above, the different urls give very different results. The json version returns location data that is nowhere close to here.

[jacque]

Yah, that was what I didn't get. I figured if you handled the text within Lc, without saving it to file, it would automatically format it the same way and save it out as whatever the OS your using used, apparently that isn't the case though?

It's the case if you import/export text as plain text, LC translates line endings. When you work with text strictly within LC, all line endings are LF. Apparently receiving data from a URL translates line endings, or else I get something different on Mac than you do on Linux.

On lin , that information comes out line specific using curl (you get the json format), so I'm wondering if you are using the api line that SparkOut mentioned, or the /json line Richard posted?

I used both yesterday. Today with : put url ("http://api.infoip.io/") I get this:

Code: Select all

{"ip":"75.72.185.108","city":"Minneapolis","region":"Minnesota","timezone":"America/Chicago","latitude":44.9948,"longitude":-93.2548,"postal_code":"55413","country_short":"US","country_long":"United States"}

Today with: put url "http://ipinfo.io/json" I get this:

Code: Select all

{
  "status": 403,
  "error": {
    "title": "Unknown token",
    "message": "Please ensure you've entered your token correctly. Refer to https://ipinfo.io/developers for details, or contact us at support@ipinfo.io for help"
  }
}

That didn't happen yesterday, but I can't remember how the data was delimited.

[bogs]

...for the 2 bits of information I need from what is returned, word and or lineOffset works fine...

...today. And depending on what the client software expects a "line" to be.

And maybe it'll work tomorrow.

But since JSONtoArray is a one-liner it seems an easy way to rest well.

Except that

1. 6.5.2 doesn't have jsonToArray...
2. I am not going to go any higher in versions just to find it...
3. Regardless of white space, the words I'm looking for aren't likely to change (and if they did, it wouldn't matter if they were in a key or not)..
4. This is software for myself, all it gets is a weather report...
5. If the gov't wants in, I may upgrade the coding style to something more regimented (and actually move higher on the machine list haha)...

In this use case, if it failed entirely tomorrow, I doubt it would be because I didn't use jsonToArray. I don't have a client looking for a software that will work forever in this instance.

That was using LC to get that url, and the value return in "it" was the page source code.
I have since got the actual data returned (needing a wait before getting the url, ugh...) but as noted above, the different urls give very different results.

Instead of 'get' and 'it', did you try just typing in 'put' ?

bogs wrote: ↑
Wed May 26, 2021 6:01 am
Yah, that was what I didn't get. I figured if you handled the text within Lc, without saving it to file, it would automatically format it the same way and save it out as whatever the OS your using used, apparently that isn't the case though?

I used both yesterday.

Heh, very very wierd. The question still stands, though, if you read a file that is not from the OS your on directly into Lc, and Lc uses LF internally, doesn't that mean that the file will have lines instead of being a single line regardless? If you never save it out, I mean.

*Edit - I parsed your answer too late and the above is irrelevant, sorry Jacque

[SparkOut]

Instead of 'get' and 'it', did you try just typing in 'put' ?

Actually yes. But whatever. Seems like the ipinfo.io site has its own quirks.

[bogs]

Was just wondering, still wierd. I guess I'll put a warning on this that IpInfo apparently doesn't like countries across the pond
(Just kidding, I may just switch it to a zip code based answer dialog anyway, this is mostly a test).