When navigating a symbolic link, path lists "actual" dir name instead of symbolic name.

[epmoyer]

If one navigates into a symbolic link, pwd reports the link name in the path (regardless of how deep one dives), but OMF shows the "actual" dir name in the path prompt instead (i.e. it does not match pwd).

OS: Mac Os 11.1 (Big Sur) theme-bobthefish: Latest commit (12b829e)

[epmoyer]

It appears that a conscious decision was made to call pwd with the -P option for some reason.

The man page for pwd says:

-P, Output the physical working directory, with symlinks resolved.

The function __bobthefish_pwd (in fish_prompt.fish) looks like:

function __bobthefish_pwd -d 'Get a normalized $PWD'
    # The pwd builtin accepts `-P` on at least Fish 3.x, but fall back to $PWD if that doesn't work
    builtin pwd -P 2>/dev/null
    or echo $PWD
end

Changing the pwd call to remove the -P (i.e. builtin pwd 2>/dev/null) results in the behavior I prefer (i.e. the Fish prompt path matches the symbolic link name), but I am not sure whether -P is intentional (it seems to be), and why, and whether an optional configuration flag is appropriate. For now I am gong to patch my local version to remove the -P.

In my use case, Dropbox (very annoyingly) forces a root folder name of Dropbox (Personal) (Because I have linked work and home accounts), and I have some code tools that don't play nicely with spaces and parenthesis in their pathnames. My local solution is to have Dropbox symbolically linked to Dropbox (Personal), and it is jarring to have Fish display Dropbox (Personal) when I have intentionally navigated into Dropbox specifically to make sure that the pwd path plays well with my tooling.

[bobthecow]

bobthefish interacts a ton with external commands (e.g. git, hg) which don't do the smart fishy things like resolving symlinks and doing case folding on case-insensitive filesystems. See #181 and #191 for example issues.

The most naive solution is to always use canonical paths for everything, which is the current implementation. It's not ideal, but it at least means that Git's idea of what a path is matches what we're calling it, so everything actually works.