PS1 fails when it uses a shell function in bash

[defjaf]

Discord username (optional)

No response

Describe the bug

My prompt is set as PS1='\h:$(dirtrim "$PWD")\$ ' where dirtrim is a function defined elsewhere in .bashrc. It fails and gives an error message in each block.

This is not such a big deal, as I can just use \h:\w\$ when [[ $TERM_PROGRAM == "WarpTerminal" ]]. I don't mind having the full path with Warp since I have the full length of the line available. (In fact my real prompt also uses shell escapes to embolden the \h, which also fails, but this is even less important.)

It is actually a bigger problem when I use Warp to ssh into other machines where I have the same prompt set, since ssh doesn't set TERM_PROGRAM=WarpTerminal. Perhaps it should? (Should I report/request this separately?)

To Reproduce

Use a user-defined shell function in PS1.

Expected behaviour

Correct prompt.

Screenshots

No response

Operating System

MacOS

OS Version

12.6

Shell Version

bash 3.2.57

Warp Version

v0.2022.09.20.08.08.stable_01

Additional context

No response

Does this block you from using Warp daily?

No

Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e

No response

[elviskahoro]

Can you share the shell function? Plus, we're not sure what we'll be doing in regards to the prompt yet. The eventual goal is to dramatically improve the native prompt. Apologies for the ambiguity.

[elviskahoro]

Can you share the shell function? Plus, we're not sure what we'll be doing in regards to the prompt yet. The eventual goal is to dramatically improve the native prompt. Apologies for the ambiguity.

[defjaf]

Here is the code from my .bashrc. The issues arise due to my dirtrim.

reset=$(tput sgr0)
bold=$(tput bold)
### see http://stackoverflow.com/questions/1616678/bash-pwd-shortening
PROMPT_DIRTRIM=2   ## works directly in bash4, but not earlier versions
if [[ $TERM_PROGRAM != "WarpTerminal" ]]; then
    dirtrim()
    {
       local name="$1" start elts
        [[ "$name" =~ ^"$HOME"(/|$) ]] && name="~${name#$HOME}"
        IFS=/ read -ra elts <<< "$name";
        start=$((${#elts[@]}-PROMPT_DIRTRIM))
        [[ $start > 1 ]] && name=$(IFS=/; echo …/"${elts[*]:start}")
        echo "$name"
     }
    PS1='\[\e[$bold\]\h\[\e[$reset\]:$(dirtrim "$PWD")\$ '
else
    PS1='\h:\w\$ '
fi

As mentioned, there is a related issue regarding the interaction with ssh, since I can't use the check for "WarpTerminal".

[BarrySmith]

This is a blocking bug for me. I use the very commonly used __git_ps1 in my prompt; https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh

The prompt always gives:

bash: __git_ps1: command not found

The shell does know the command, since I can just run it at the prompt

$ __git_ps1 (barry/2022-09-12/fix-mat-preallocation=)

So it seems somehow when Warp is evaluating PS1 it does not have access to the shell functions?

Waiting eagerly for a fix.

[adamteller]

I encountered similar issue. In iTerm2 and in Mac Terminal, the git prompting worked great. After installing Warp, the same code to init the bash prompt stuff made warp break after one command. To work around it, I added the following to my ~/.bash_profile file

if [ "$TERM_PROGRAM" != "WarpTerminal" ]; then    
    if [ -f "/usr/local/opt/bash-git-prompt/share/gitprompt.sh" ]; then
       __GIT_PROMPT_DIR="/usr/local/opt/bash-git-prompt/share"
       source "/usr/local/opt/bash-git-prompt/share/gitprompt.sh"
    fi
else
    echo "Welcome to $TERM_PROGRAM"
fi

[rodrigdav]

I am running into this too. Would love to see some sort of fix.

[boywijnmaalen]

same issue for me, somehow WARP is unaware of the __git_ps1 cmd (even when specifically sourcing the git-prompt.sh file)

[zachbai]

Hey all, I'm suspecting this is a bug that crops up when using an older version of bash (anything <4.4) -- you can inspect your current bash version by running echo $BASH_VERSION.

If this is indeed the case, installing and using the homebrew version bash (which I believe defaults to 5.2) should address the issue as a workaround.

Aside from the workaround, I have an idea for the fix (which won't require installing a newer bash version), but no firm ETA on that yet. I'll try to get started on it soon.

[boywijnmaalen]

@zachbai thanks for your reply, I'm using;

$ echo $BASH_VERSION

3.2.57(1)-release

[dannyneira]

Closing as resolved!