-- Leo's gemini proxy
-- Connecting to thrig.me:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
curl wttr.in
This however does not fit within 80x24 terminals, and having to temporarily resize a terminal to make that one application work seems dubious. Maybe there's a flag to make the display less full of empty space and lines?
Has too many lines of code to review due to vendoring of unicode and other things. Probably I need to get better at auditing large Go codebases.
Does not compile on OpenBSD by default; it uses pkg-config only for libcjson but not for pcre2 nor libcurl which then fail to link. After some fiddling around:
doas pkg_add cjson curl pcre2
export AUTOMAKE_VERSION=1.16
export AUTOCONF_VERSION=2.71
autoreconf -i
CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib -lpcre2-8" ./configure
make
Also nowa uses an unportable 32-bit time counter; OpenBSD moved to a 64-bit epoch some time ago.
forecast.c:75:15: warning: incompatible pointer types passing 'long *' to parameter of type 'const time_t *' (aka 'const long long *') [-Wincompatible-pointer-types]
localtime_r(&ts, &last_updated);
^~~
Signed integers can only go so far. But hey! 2038 is still a long ways off. That's plenty of time to fix all the code. (There will be an uptick in contract work starting somewhere around 2036.)
$ perl -MPOSIX=strftime -E 'say strftime "%Y-%m-%d", gmtime 2**31'
2038-01-19
Anyways, once compiled (and restricted with pledge and unveil to allow the minimum necessary access to the system) nowa grants access to a lot of different weather station products. Still not sure how to get a forecast out of it.
Chilly is good:
though last I looked it was showing "cloud" in 14 of 24 lines. Maybe if I lived somewhere where the weather matters--cloudy with scattered showers and rare snow, mixed with clear cold days until sometime in June or early July--or had a job where the weather mattered I'd look at it more?
More ideas, including some minimal URL parameters and JSON parsing:
latlong='33.7737,-118.1365'
url=$(curl -sS "https://api.weather.gov/points/$latlong" | jq -r '.properties.forecastHourly')
curl -sS "$url" | jq -r '.properties | .periods[0].temperature, .generatedAt'
This points to the problem where an application may need quite a lot of complexity to support whatever a user may want (or to even compile on OpenBSD) and even then the application may not suit everyone, maybe because the application is now too bloated from code to support all those different users. It may be faster to write a program that does exactly what you want rather than spend time trying to install and learn how to use an application. This assumes there is a good API with good documentation. Applications can likewise be quite weak at documentation. It also assumes one is not terrible at coding, which most are. And that the code will not take too long to write, versus figuring out some application...
On the other hand, two curl and two jq forks per request will use a bit more CPU than an equivalent program.
tags #weather
-- Response ended
-- Page fetched on Tue May 21 20:27:53 2024