Hi Guix! A common convention for where to set PS1 is in .bashrc, not .bash_profile [1-3]. Unfortunately home-bash-service doesn't support this convention for login shells.
home-bash-service generates a default .bash_profile that follows these steps: 1. Source .profile 2. Source .bashrc 3. Set PS1 if guix-defaults? is truthy This means that any PS1 configuration in .bashrc is overwritten by .bash_profile for login shells specifically. This is visible in a TTY, but also in WSL, which defaults to opening a login shell. PS1 will be Guix's predefined value instead of the value set in .bashrc. Setting guix-defaults? to #f has many side effects, so I don't feel that is a valid solution. A comment in home/serivces/shells.scm suggests setting PS1 via environment-variables since that is appended to the end of .bash_profile. This is fine for simple prompts, but complicated prompts are often split apart into separate bash functions and variables. Either an implicit dependency between .bashrc and .bash_profile is created, or .bash_profile balloons into a mega-file while the conventional wisdom is to keep it as simple as possible. environment-variables also exports PS1, causing it to become an environment variable, not a shell variable. This might cause some odd behavior when subprocesses inherit it. [4] Some possible solutions: 1. Move default PS1 to bashrc, right after serializing %default-bashrc 2. Keep default PS1 in .bash_profile, but before loading .bashrc 3. Add a set-prompt? field to home-bash-configuration Of the 3, I think 1 is the best and plan to submit a patch for it soon. I'm opening the bug in case anyone thinks I missed something. [1] https://unix.stackexchange.com/a/549075 [2] https://superuser.com/a/789465 [3] https://superuser.com/a/789454 [4] https://unix.stackexchange.com/a/44000 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.