Use C.UTF-8 as locale when invoking external awk program

[guilherme-puida]

The en_US.UTF-8 locale is not guaranteed to be installed, and it quite often isn't by default.

The C.UTF-8 locale was introduced as a Debian-specific locale, but was later upstreamed into glibc 2.35 [1].

This patch fixes failures when running interpreter tests on systems where the en_US.UTF-8 locale is not present. It also changes the locale on goawk_test.go, similar to !174 [2].

1: https://sourceware.org/bugzilla/show_bug.cgi?id=17318
2: #174

---

I ran into some test failures when packaging goawk for Debian. I also ran the
test suite on a fresh Arch container, which failed for the same reason. This
seems like a reasonable fix :^)

[guilherme-puida]

I think MacOS does not support C.UTF-8 :(

I changed the commit to use en_US.UTF-8 when running the test on darwin.

[benhoyt]

Thanks for this. These locale environment variables are all a bit messy, aren't they? I'm okay with this fix, however, let's hide the messiness inside a function so it's easy to update in one place (later we could use locale -a to see if it's present, for example). Perhaps a func awkLocale() string which returns "" on Windows, and the correct locale on others.

[guilherme-puida]

Sure! I'm not too sure where this awkLocale function should reside, though. Stuffing it into interp looks wrong, and I feel like it should be somewhere in internal.

[benhoyt]

Just at the bottom of interp_test.go below normalizeNewlines is fine.

[guilherme-puida]

If it is in interp_test then goawk_test can't import it :(

[benhoyt]

Oops, I'd missed the fact that the first one was in goawk_test.go. In that case, I think what you have is reasonable. Let's do it.