Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

test_run_with_command_flags fails on macOS (BSD printenv doesn't support --version)

Closed Beginner friendly
  • Is something wrong?
#708 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
cli, testing

Research direction

Start with tests/test_cli.py::test_run_with_command_flags and inspect how it invokes dotenv run printenv --version. Replace the OS-specific sentinel with the suggested Python argv-echoing command, then run this test with pytest or tox on macOS and confirm the flag-forwarding assertion passes.

Written by the indexing model from the issue text.

Description

Description

tests/test_cli.py::test_run_with_command_flags fails when running the test suite (via tox or pytest) on macOS.

tests/test_cli.py::test_run_with_command_flags FAILED

AssertionError: Unexpected exit code 1 (expected 0)
stdout:

stderr:
printenv: illegal option -- -
usage: printenv [name]

assert 1 == 0

Root cause

The test runs dotenv run printenv --version and asserts it exits 0, to verify that dotenv run forwards flags to the wrapped command instead of parsing them itself (added in #607 / #612).

  • On Linux, printenv is GNU coreutils' version, which supports --version and exits 0.
  • On macOS, printenv is the BSD version, which does not support --version at all, and exits 1 with printenv: illegal option -- -.

So the test is actually working as intended (dotenv run correctly passes --version straight through to printenv rather than swallowing it), but the assertion only holds on systems with GNU printenv.

Why this hasn't been caught in CI

.github/workflows/test.yml only runs the test matrix on ubuntu-latest and windows-latest - there's no macos-latest job, so this has never surfaced there.

CONTRIBUTING.md tells contributors to just run tox or pytest, with no mention that the suite assumes a GNU userland / Linux, so a macOS contributor following the documented steps hits this with no explanation.

Suggested fix

Replace the OS-specific sentinel command (printenv --version) with something that behaves identically across GNU/BSD/Windows, e.g. a small python -c "..." snippet that just echoes its argv, so the test only cares about flag-forwarding behavior rather than a specific external tool's flag parsing.

Environment

  • macOS (Darwin), tested via tox locally
  • Reproducible with plain pytest too, since it's just calling the system printenv
Dominant language
Python
Stars
8.9k
Forks
600
Avg merge
4d 23h
Merged PRs (30d)
4

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from theskumar/python-dotenv

All issues in theskumar/python-dotenv

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.