As promised on irc, here's a sanitizer that's more liberal about what can be in an env var string. This strips leading and trailing spaces from both the varname and the value, but preserves embedded spaces in both (embedded spaces in varnames are not too useful, but no reason to disallow them either really). It also leaves embedded quotes unmolested, but does strip leading and trailing quotes. Unlike the original, it leaves the original string untouched and composes the sanitized string into a new buffer (because it's easier to get everything right that way).

static void
sanitize_envline(char *result, const char *src)
{
	const char *eq;
	char c, *dst;
	bool leading;

	/* If there is no '=' it's not a well-formed name=value line. */
	if ((eq = strchr(src, '=')) == NULL) {
		*result = 0;
		return;
	}
	dst = result;

	/* Copy chars before the '=', skipping any leading spaces/quotes. */
	leading = true;
	while (src < eq) {
		c = *src++;
		if (leading && (isspace(c) || c == '"'))
			continue;
		*dst++ = c;
		leading = false;
	}

	/* If it was all leading space, we don't have a well-formed line. */
	if (leading) {
		*result = 0;
		return;
	}

	/* Trim spaces/quotes immediately before the '=', then copy the '='. */
	while (isspace(dst[-1]) || dst[-1] == '"')
		--dst;
	*dst++ = *src++;

	/* Copy chars after the '=', skipping any leading whitespace. */
	leading = true;
	while ((c = *src++) != 0) {
		if (leading && (isspace(c) || c == '"'))
			continue;
		*dst++ = c;
		leading = false;
	}

	/* If it was all leading space, it's a valid 'var=' (nil value). */
	if (leading) {
		*dst = 0;
		return;
	}

	/* Trim trailing whitespace and quotes. */
	while (isspace(dst[-1]) || dst[-1] == '"')
		--dst;

	*dst = 0;
}

I guess I forgot the free(linep) in this version.

If we change this documentation a bit, the limitations of the lexer seem almost like a feature...

.Ar setting
must be of the form
.Dq Va Qo name Qc = Qq value .
Quotes are required around the value.
Quotes are required around the name only if it contains
non-alphanumeric characters.

"Oh that? That's neither a wart nor a bug, good sir! That there is a feature!"

You're not wrong, though. Let's look at the upsides:

• It's still pretty clear and functional, albeit obviously different from loader.conf(5) environment and env files
• If you get it wrong, you get a syntax error instead of incorrect behavior

It's not really different though... loader.conf theoretically requires quoted lhs, but single-word things work fine unquoted so people do that. This would be the same (except unquoted numbers don't work). Also, env files would work exactly the same with the new sanitizer, you could put "a.b"="thing" in an env file and get exactly the same result as you would with envvar "a.b"="thing".