I was a long time tcsh user and I have used a custom prompt, which includes the date/time, host, and a largish path. In the past, when I've used venv, I would switch to bash first, just because everything's geared toward bash, and I liked that the current environment would be added to the prompt, and I had left the bash prompt uncustomized. However, since I've been using bash more and more, I decided to migrate a version of my custom tcsh prompt. To do that, I added this to my bash profile:

changeprompt() { DIR=`dirs | perl -e '$p=scalar(<STDIN>);$p=~s/.*(?=\S{40}\Z)/.../;print($p)'`;export PS1="\h[\D{%F %T}]:$DIR\$ "; }

It leaves me with a prompt like this:

gen-rl-macbookair[2021-02-12 14:01:24]:~/PROJECT-local/TRACEBASE$

I wanted a longer path in the prompt that is manually truncated with an ellipsis at a given length based on characters instead of directory depth, which is why I set PROMPT_COMMAND.

However, I realized yesterday when I started working on a venv for the first time in a long time, that activating a venv would not change the prompt to prepend (environment_name) to the prompt, since I had set PROMPT_COMMAND.

I fixed the issue by editing the activate script to unset COMMAND_PROMPT upon activate and reset COMMAND_PROMPT upon deactivate...

But I'm wondering if there exists a better way to maintain a custom command prompt like this that allows for a variably prepended string that a venv activate script adds - without needing custom edits to any activate script.

  • Problem is the activate venv setup script use PS1 instead of COMMAND_PROMPT
    – Welgriv
    May 12, 2021 at 13:48
  • Yeah. That's the problem. PS1 features don't support the feature I want of limiting the path length, which is why I use PROMPT_COMMAND. I want to see as many dirs of my path within 40 characters. That's what my PROMPT_COMMAND does. I think all I should need to do is store the old prompt command when a new env gets activated and restore it when deactivated. Or maybe I can change my prompt command to use the existing PS1 value, or modify it instead of set it.
    – hepcat72
    May 12, 2021 at 14:19

1 Answer 1


As a (bad) workaround, you can define bash functions that set and unset prefix for PS1, and call these when you activate/deactivate your venv instead of source activate and deactivate.

In your bashrc:


PROMPT_COMMAND='changeprompt && set_prompt_prefix'

    source activate && PROMPT_PREFIX="(venv) " && alias 'deactivate'='deactivate_venv'

    deactivate && PROMPT_PREFIX=

Then you have to call activate_venv instead of source activate. deactivate venv base function is aliased with my deactivate_venv so that prefix is always removed.

Beware that the prefix will always be (venv) . An even smarter solution could retrieve the venv name or directory and set it as prefix.

  • The venvs I have, have their own activate scripts that modify PS1 and add different prefixes. My error-prone workaround has been to edit those scripts to set/restore PROMPT_COMMAND, but other venvs tend to get in the way and I end up with stale prompts that don't update. Part of the problem (with my question) is I over-simplified the example. I should probably add more detail and examples to my question. Like, the activate scripts take a path, and switching between different venvs, etc.. This is a decent idea though.
    – hepcat72
    May 12, 2021 at 15:31
  • 1
    Editing each new venv you create seems really painful for me since it all supposed to be auto-generated. Problem root is that python does not consider any use case like ours when we are working with PROMPT_COMMAND is might be a good idea to ask for a change request or warn for a bug somewhere.
    – Welgriv
    May 20, 2021 at 14:36
  • It is. Hence my question. That's a good suggestion.
    – hepcat72
    May 20, 2021 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.