direnv
direnv copied to clipboard
Unable to set up PS1
Describe the bug
Unable to change PS1 using direnv following the instructions at direnv wiki on PS1.
To Reproduce I have the following relevant entries in my files.
.bashrc
DEFAULT_PS1='\[$(ppwd)\]\u@\h:\w$(__git_ps1 " (%s)")'
# add some more things to DEFAULT_PS1, conditionally
DEFAULT_PS1+='> '
PS1=${CUSTOM_PS1:-$DEFAULT_PS1}
# optional bashrc file extensions
for f in ~/.bashrc_*; do test -s $f && . $f || true; done
eval "$(direnv hook bash)"
.envrc
export KUBECONFIG=~/.config/kube/homelab.yaml
export KUBE_PS1_ENABLED=on
export CUSTOM_PS1='$(kube_ps1) $ '
PATH_add scripts
I have allowed the latest version of the .envrc
with direnv allow
. However, when changing to the directory, the custom PS1 value is not set, although the values seems to be right
$ cd -
/home/robert/sources/oss/sling-cloud-native
direnv: loading .envrc
direnv: export +CUSTOM_PS1 +KUBE_PS1_ENABLED ~KUBECONFIG ~PATH
$ echo $PS1
\[$(ppwd)\]\u@\h:\w$(__git_ps1 " (%s)")$(kube_ps1)>
$ echo $CUSTOM_PS1
$(kube_ps1) $
I am not sure how the solution in the wiki is supposed to work, as apparently the value of PS1 is set to the DEFAULT_PS1 when the .bashrc
file is loaded the first time and is not re-evaluated as part of the direnv
hook.
Expected behavior PS1 should be set.
Environment
- OS: openSUSE Tumbleweed
- Shell: bash-5.0.11-2.1.x86_64
- Direnv version: direnv-2.17.0-2.4.x86_64
Bit by this bug as the recent 2.21.x series seems to correct the enforcement mechanism. The only explanation for being blocked seems to be a mac bug. Is this bug unresolved or can the blocking only be enforced of effected systems?
@jberryfs - what do you mean by "a mac bug"?
From the wiki:
There was a bug in macOS' bash 3.x implementation that would crash the shell if PS1 was unset.
but direnv
block on all platforms and seems like the bug does not exist anymore either.
Ah, right. I thought you said what I reported is a bug only on Mac. But I agree, this workaround for a very old bug could be removed.
I should probably explain the problem better. The core issue is that PS1 is a local variable. If it gets set by direnv on load, it wouldn't know how to restore the local variable when unloading the environment. Instead the shell ends-up with an empty prompt. The macOS bash just makes the problem worse by crashing.
@zimbatm Could you save PS1 into another environment variable (eg. DIRENV_PS1) and restore that on unloading?
The issue is how to backup and restore the local PS1 variable. There would need to be a dedicated mechanism for that.