direnv icon indicating copy to clipboard operation
direnv copied to clipboard

Unable to set up PS1

Open rombert opened this issue 5 years ago • 7 comments

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

rombert avatar Oct 23 '19 15:10 rombert

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 avatar Jan 28 '20 21:01 jberryfs

@jberryfs - what do you mean by "a mac bug"?

rombert avatar Jan 29 '20 08:01 rombert

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.

jberryfs avatar Jan 29 '20 15:01 jberryfs

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.

rombert avatar Jan 29 '20 17:01 rombert

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 avatar Jan 29 '20 22:01 zimbatm

@zimbatm Could you save PS1 into another environment variable (eg. DIRENV_PS1) and restore that on unloading?

paranoidi avatar Mar 25 '21 11:03 paranoidi

The issue is how to backup and restore the local PS1 variable. There would need to be a dedicated mechanism for that.

zimbatm avatar May 11 '21 10:05 zimbatm