Environment Variables

Have you ever run AI tool like this one that needs an API key to talk to OpenAI? It is a bad idea to just write this in the code:

# inside my python code ...
api_key = "sk-ABCDEF123456"

Why? Because if you commit your code to GitHub, people can see your API key 🙃.

It is also a bad idea to pass the API key as command line argument like this:

$ python3 llama.py api="sk-ABCDEF123456"

Why? Because if you run the program on a public workstation, anyone on the same workstation can see your secret by looking at top or ps.

Instead, the best practice is to pass the API key or any secret information as environment variable:

import getpass
import os

if "OPENAI_API_KEY" not in os.environ:
    os.environ["OPENAI_API_KEY"] = getpass.getpass("Enter your OpenAI API key: ")

Before we run the code, we set the environment variable by pasting the API key we get from OpenAI: export OPENAI_API_KEY=sk-ABCDEF123456 Environment variables let us pass context to the code we’re running without hard-coding it in the code.

Real-World Example: Starting a PostgreSQL Container

Docker container images often don’t change once they are built, meaning that their contents (binaries, scripts, configurations) are fixed. Environment variables help us inject dynamic behavior, such as API keys or password, into a container at runtime.

The following command launches a PostgreSQL database container. Note the -e flags: they inject environment variables into the container (more customizable variables here).

docker run --name some-postgres \
  -e POSTGRES_USER=myuser \
  -e POSTGRES_PASSWORD=mypassword \
  -e POSTGRES_DB=mydatabase \
  -d postgres

Under the hood, Docker calls execve() to start the database process. The database process reads values like POSTGRES_USER from the environment.

Question: Why not just use command-line arguments: docker run postgres --user=myuser --password=mypassword?

How PTT Did It (The Old Days)

In the 1990s, PTT was run at 杜奕瑾’s dormitory, manually from a terminal. To keep the program running, PTT called a daemonize() function from logind, which can handle thousands of log-ins per second. The daemonize() function works like this:

• fork() → parent exits, child keeps running in the background.
• setsid() → child starts a new “session” with no terminal attached.
• fork() again (double fork) → ensures the process can never accidentally grab a terminal again.
• redirect input/output → stdin/stdout/stderr go to /dev/null or log files.
• write a PID file → so admins can later find and control the daemon.

That’s why even if the admin logged out, PTT kept running

Here’s the specific code that redirect stderr to logfile. A daemon has no screen, so we send errors into a file.

if (logfile) {
    if ((fd = OpenCreate(logfile, O_WRONLY | O_APPEND)) < 0) {
        perror("Can't open logfile");
        exit(1);
    }
    if (fd != 2) {
        dup2(fd, 2);
        close(fd);
    }
}

Here’s the code that sends stdin and stdout to black hole

if ((fd = open("/dev/null", O_RDWR)) < 0) {
    perror("Can't open /dev/null");
    exit(1);
}

dup2(fd, 0);
dup2(fd, 1);
if (!logfile)
    dup2(fd, 2);

This is equivalent to running this in a shell:

$ ./ptt </dev/null >/dev/null 2>>"$logfile"

Today: systemd Instead of DIY

On modern Linux servers, you rarely write daemonize() yourself. Instead, you write a systemd service unit:

[Service]
ExecStart=/usr/local/bin/myapp
Environment="API_KEY=sk-XXX"
Restart=always

Systemd then:

• starts your program in the background,
• keeps it alive if it crashes,
• capture error logs (so you can debug later),
• injects environment variables.

Did you see systemd being the ancestor of all the processes in the system? These processes like databases, web servers, or messaging systems. They run for months, listening on a network port and responding to requests. If they ever crash, they must be restarted immediately to keep the system available.