|
Off Topic
|
|
Quote:Can you force it to a predictable format by using an Accept-Language header? Did a quick experiment. Adding the header "Accept-Language: en-CA" didn't produce the Canadian results that I got when spoofing my location in the browser.
|
Off Topic
|
|
You could use something like https://ipstack.com/ to get the lat/lon from your IP. You are limited to 100 calls per month for free, but that should be easy to avoid if you only grab it when the IP changes, or limit it even further to only check when
|
Off Topic
|
|
Originally Posted By: tfabrisAlong the lines of Roger's suggestion, I wonder if there's a Google API for returning those kinds of results in a JSON, so that I don't have to scrape the HTML? Yes there is, but it's not free. After 100 queries per day,
|
Off Topic
|
|
Based on my initial experimentation, sunrisesunset.io requires entering a lat/long, you can't use a named location, nor can you omit the location. Which is odd: It will use the the internet location to determine the timezone, why can't it use the sam
|
Off Topic
|
|
Quote:Can you force it to a predictable format by using an Accept-Language header? Great idea! I hadn't thought of that. Worth experimenting. Quote:I used this API for something I did: https://sunrisesunset.io/api/ Didn't even know that existed! Als
|
Off Topic
|
|
At some point, it has to be easier to just give up on using Google. I used this API for something I did: https://sunrisesunset.io/api/
|
Off Topic
|
|
Frame challenge: why is Google giving you differently-formatted results? Can you force it to a predictable format by using an Accept-Language header?
|
Off Topic
|
|
I once wrote a program in Q-Basic that displayed right there on the screen: "Hello, world." If I recall correctly, it only took me a couple hours to debug it and get it working. So if you need any further help with this project, be sure an
|
Off Topic
|
|
Mark and Peter, thanks so much for your help and suggestions! My final fix was a bit different from your suggestions for a few reasons: I wanted it to be less fancy and more readable, I wanted it to be less greedy about getting results, I needed it t
|
Off Topic
|
|
I mashed this up using some of the original code. It doesn't have the latest/best matching for AM/PM, but it does know how to find the correct strings: Code:
#!/bin/bash
userAgent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (K
|
Off Topic
|
|
There can be a lot of text in the results, and though the proper result is usually the first one in the search results, I want to avoid greedily grepping for "*" as much as I can avoid it. It might return a bunch of stuff I don't want. I ce
|
Off Topic
|
|
Right!
|
Off Topic
|
|
I think that's what the "-i" does. Peter
|
Off Topic
|
|
Originally Posted By: peterCode:grep -o -i '[0-9]+[^0-9]+[0-9]+[^AP]*[AP][^M]*M' Also handle upper/lowercase: Code:grep -o -i '[0-9]+[^0-9]+[0-9]+[^aApP]*[aApP][^mM]*[mM]'
|
Off Topic
|
|
You know, you might be better off matching on anything between the digits and the am/pm; that would be more robust in the face of any future changes to the website: Code:grep -o -i '[0-9]+[^0-9]+[0-9]+[^AP]*[AP][^M]*M' Peter
|
Off Topic
|
|
Turns out it's more complicated than that. I want to be able to debug the code on macs, pc's, and on the Synology, and the possible locale variable can differ depending on what system you're running it on. For example, on the Synology it's: en_US.ut
|
Off Topic
|
|
Mark and Peter, thanks so much for your help. I'm going to fix the production code with that locale fix, and also fix the parser so that it gets the alternate forms of "a.m." and "pm" as Mark pointed out. Thanks again!
|
Off Topic
|
|
Originally Posted By: mlordYou'll want to put the export keyword in front of the assignment. Eg. export LC_ALL=en_US.utf8 BINGO. That command fixed the bug and now the grep statement works as expected again.
|
Off Topic
|
|
You'll want to put the export keyword in front of the assignment. Eg. export LC_ALL=en_US.utf8
|
Off Topic
|
|
Quote:If that's the issue, than you can force grep to use a proper locale by setting LC_ALL=en_us.UTF-8 yourself in your script. I tried all of these: Code:
LC_ALL=en_us.UTF-8
LC_ALL="en_us.UTF-8"
LC_ALL=en_us.UTF8
LC_ALL="en_us.
|
Off Topic
|
|
Interesting! Indeed the value of $LC_ALL is different, depending on whether I'm running it from the shell or running it from task manager. Running it from the shell, I get "en_US.utf8" and running it from task manager I get a blank/null va
|
Off Topic
|
|
Get the script to echo the value of $LC_ALL. Looks like when it runs as you, it's in a Unicode locale (e.g. "en_us.UTF-8" with UTF-8 support) but when it runs under the scheduler it's in a legacy locale (probably "C") where U+202F
|
Off Topic
|
|
Very interesting! Indeed when I spoof my location in the browser and point it to Montreal, I get the other format that you describe. Seems to be a localization thing; the Canadian version of the formatting prefers the lower case with the dots. Strang
|
Off Topic
|
|
When I do the same google access here, the Sunrise time shows up in a different format. It looks like this: 6:58 a.m. Sunset comes out like this: 7:16 pm You may or may not also have to cope with those someday.
|
Off Topic
|
|
It always helps one debug one's own code by trying to explain the code to somebody else. I have a workaround now. I'm not sure WHY this workaround succeeds, or more specifically, why it's needed in that specific situation, but here it is. I had to c
|