Windows terminal displays "PS>" instead of the path

I am setting up a new computer and can't get my oh-my-posh configuration working on my Powershell terminal. Powershell v7.4 is installed.

I have copied this across from my previous PC which is displaying correctly.

Profile ps1 (from code $PROFILE):

oh-my-posh --init --shell pwsh --config "C:\dropbox\oh-my-posh\themes\mytheme.omp.json" | Invoke-Expression
Import-Module -Name Terminal-Icons
$env:POSH_GIT_ENABLED = $true

Omp file:

    {
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "blocks": [
    {
      "alignment": "left",
      "segments": [
        {
          "background": "#1478DB",
          "foreground": "#000000",
          "leading_diamond": "\ue0b6",
          "trailing_diamond": "\uE0B0",
          "properties": {
            "style": "full"
          },
          "style": "diamond",
          "template": "{{ .Path }} ",
          "type": "path"
        },
        {
          "background": "#3AD900",
          "background_templates": [
            "{{ if or (.Working.Changed) (.Staging.Changed) }}#FFC600{{ end }}",
            "{{ if and (gt .Ahead 0) (gt .Behind 0) }}#FFCC80{{ end }}",
            "{{ if gt .Ahead 0 }}#B388FF{{ end }}",
            "{{ if gt .Behind 0 }}#B388FF{{ end }}"
          ],
          "foreground": "#000000",
          "leading_diamond": "<transparent,background>\uE0B0</>",
          "trailing_diamond": "\ue0b4",
          "properties": {
            "fetch_stash_count": true,
            "fetch_status": true
          },
          "style": "diamond",
          "template": " {{ .HEAD }}{{ if .Staging.Changed }}<#FF6F00> \uf046 {{ .Staging.String }}</>{{ end }}{{ if and (.Working.Changed) (.Staging.Changed) }} |{{ end }}{{ if .Working.Changed }} \uf044 {{ .Working.String }}{{ end }}{{ if gt .StashCount 0 }} \ueb4b {{ .StashCount }}{{ end }} ",
          "type": "git"
        }
      ],
      "type": "prompt"
    }
  ],
  "final_space": true,
  "version": 2
}

Display (working on PC #1):

Display (not working on new PC #2):

On the new PC I'm only seeing PS> and the command prompt.

If I run oh-my-posh --init --shell pwsh --config "C:\dropbox\oh-my-posh\themes\cobalt2.omp.json" | Invoke-Expression on the command line then the correctly formatted path appears for a short time, then reverts back to PS>. This tells me that oh-my-posh is correctly installed, and the omp file is also correctly configured.

All the other windows terminal settings from PC #1 have been backed up and copied across to PC # 2 too.

What other settings might I have missed to prevent the oh-my-posh path from being displayed?

---

UPDATE (debugging info)

Following the debugging information from @mklement0 below the following errors occurred:

Can anyone provide any information on these?

Note:

• Generally, the symptom implies that an unhandled terminating error (exception) occurs in the prompt function (the function that prints the string at the start of each interactive prompt , causing PowerShell to fall back to its built-in default prompt string (PS>).

• The instructions below do not solve your problem, they help you troubleshoot it.

  • Update: You report that the problem turned out to be:
    "I was missing posh-git and the variable setting line $env:POSH_GIT_ENABLED = $true was failing."

---

Examining (the most) recent error(s):

As Jan De Dobbeleer points out, it may be sufficient to simply examine what error(s) occurred when the prompt function last executed, via the automatic $Error variable, which records all errors that occur in a session:

• To start with a clean slate, clear the current value of $Error:

  $Error.Clear()
  

• After having submitted this command interactively, the prompt function immediately re-executes, and $Error will then contain any error(s) that it triggered.

To examine the details of the error(s) that occurred:

• If you're running PowerShell (Core) 7+, use the Get-Error cmdlet:

  Get-Error # most recent error ($Error[0])
  
  $Error | Get-Error # ALL errors
  

• In Windows PowerShell, use the following instead (which produces less friendly output:

  $Error[0] | Format-List * -Force # most recent error ($Error[0])
  
  $Error | Format-List * -Force # ALL errors
  

Note:

• Since you're looking for a terminating (fatal) error, only $Error[0] should be of interest in your case.

• Generally, note that $Error also reflects non-terminating errors, including silenced ones (-ErrorAction SilentlyContinue), which therefore may not be indicative of an actual problem. (By contrast, -ErrorAction Ignore prevents recording in $Error.)

• Look for ScriptStackTrace in the output to see where the error occurred; in Get-Error output, InvocationInfo provides additional details.

• If that doesn't give you enough context, you can debug the function step by step to follow the flow of control, as explained next.

Debugging the prompt PowerShell function:

• Set a breakpoint for the prompt function so that the debugger is invoked every time the function executes:

  $bp = Set-PSBreakpoint -Command prompt
  

  • Use the following to remove it again later (or just start a new session):

     $bp | Remove-PSBreakpoint
    

• Given that you've just submitted a command, the prompt function is immediately invoked, and you can start debugging:

  • Once in the debugger, submit ? to see a list of commands, l to list the function's source code; see the conceptual about_Debuggers help topic for detailed guidance.

  • In the simplest case, submit v to skip from whole command to whole command, or s to step into a specific command, if possible. Just pressing Enter repeats the latest action (v, s, or l)

  • The source-code line containing the command about to be executed prints, with the command underlined with ~~~~~~~.

  • Repeat v (or s) until the debugger unexpectedly exits: The last command executed was the one that caused the terminating error (exception).

Here's a screenshot demonstrating such a session:

• A dummy prompt function is defined that provokes a statement-terminating error (exception), with 1 / 0

• A breakpoint is set for the function - by default at the start of the function, and having just submitted a command immediately invokes the prompt function and therefore enters the debugger.

• v is used to move from command to command, with the next command to execute underlined with ~~~~~~~~

• Upon execution of 1 / 0, the statement-terminating error that occurs both aborts the function execution and exits the debugger, pinpointing it as the offending command.

• If the offending command is itself a PowerShell function or script, you'll need to repeat the process and step into it during debugging, using s instead of v.

• Either way, $Error will reflect the error(s) that occurred.