Fix warnings not being printed #560
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since a few days ago (so I assume starting at direnv 2.36.0), the
DIRENV_LOG_FORMAT
environment variable is not set by default. This breaksnix-direnv
every time it's called withstrict_env
due to an unbound variable error.Even if the variable was accessed safely, warnings won't be rendered anymore because it's empty and we skip printing anything when that happens.
With this approach, we use the stdlib
log_status
, and just wrap it around ANSI escapes for the yellow color.This has the advantage of delegating the logging format logic back to
direnv
, but it might be possible that at some point in the futuredirenv
sanitizes the strings and breaks this solution. However, the alternative is to keep relying onDIRENV_LOG_FORMAT
, which will break by default, and in doing so we would also be ignoring the newlog_format
option indirenv.toml
.Other thing I tried to get colored logs "idiomatically" was to embed them inside the
log_status
arguments, not around it:log_status "$(printf "%b" $color_warning)${_NIX_DIRENV_LOG_PREFIX}${msg}$(printf "%b" $color_normal)"
This makes the output look like this (note that the

direnv:
prefix is not colored):But it would be a valid alternative if, for example, the behaviour at direnv/direnv#884 is restored.