Reading a .env file

--env-file=.env loads one and grants env for exactly the names in it.

scua --env-file=.env app.scua

Naming the file is the grant. You do not pass --allow-env as well, and you do not write the file's key list a second time where the two copies can drift apart.

Notice what that gets you. With --env-file on its own, the script sees the file's names and nothing else, so an AWS_SECRET_ACCESS_KEY sitting in your shell cannot reach it. Add --allow-env=NAME when you want particular real variables too.

A real environment variable beats the file, which is what makes .env a defaults file:

DB_HOST=prod.internal scua --env-file=.env app.scua

The flag repeats and is applied in order, and nothing replaces a name that is already set, so an earlier file wins over a later one.

For a file's contents rather than its authority, dotenv.parse reads the same format as ordinary data with no capability at all. That is the case where you are inspecting someone else's .env rather than running under it. One implementation backs both, so the loader and the parser cannot come to different conclusions about the same file.

The grammar is the usual one: KEY=value, comments, an optional export prefix, both quote styles, values that span lines. Two things in it will catch someone out. A Windows path wants single quotes, because "C:\temp" contains \t and reads as a tab, while 'C:\temp' is taken verbatim. And ${VAR} is not interpolated, it stays literal text, because a value that could name another variable would be a way around the allowlist you just wrote.