env parsing quirks

[mcandre]

Fedora dumps multiline string data directly onto stdout for env with plain LF's:

$ env
FEDORA_CHANGELOG=* Sun Feb 1 2026 Bob <bob@bobsautoparts.test>
- Prototype
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/.venv/bin
VERBOSE=1
...

There is probably no safe, distro independent way to safely parse data piped in from env. Because the value may itself begin a line with <VAR>=.

Frankly, requiring the user to pipe env in, is needlessly laborious. And breaks native Windows.

Fortunately, there is a safer, better UX way:

1. Query an environment variable JINJA_ENV.
2. When JINJA_ENV is present, then use the standard library to loop over environment variables and build up the data dictionary.

https://www.geeksforgeeks.org/python/python-os-getenv-method/

[mattrobenolt]

Is this not solved with https://github.com/mattrobenolt/jinja2-cli/blob/main/docs/examples.md#environment-variables ?

[mcandre]

That's a lot of boilerplate to manage, when dealing with dozens of, primarily env var data.

[mcandre]

printenv may behave more predictably than env. The former is a POSIX standard. Worth testing with a Fedora Docker image.

[mattrobenolt]

I'm sorry. I really don't understand what you're trying to do.

You can't reasonably pipe in from env.

There is a helper function provided to retrieve env vars.

What boilerplate are you talking about?

Can you just give me a concrete reproducible issue and I'm happy to take a look, but as of now, it's just not clear to me what behavior you expect to work.

[mcandre]

To clarify, all of my template variables originate from data in environment variables.

And my application currently uses a lot of environment variables.

Working around the boilerplate via rsubst, which has the bonus effect of no runtime interpreter required.

[mcandre]

Indeed, env does not format multiline values in a predictable manner. printenv is better, which is what some Jinja CLI's use.

Yet, pipefail is a problem.

But a flag to automatically populate the default Jinja namespace with corresponding env vars, would be nice.