Old question, I know, but dusted off by a separate new answer recently. The question, and existing answers, sound to me a bit like:
Every time I get out of bed, I cut my foot on the broken glass on floor next to the bed. What should I do?
- Put a bandage on your foot every time you cut your foot after getting out of bed?
- Or clean up the broken glass?
I hate to be so pedantic, but it seems to me that all of the existing answers (over many years) here have essentially recommended the "bandage" option.
Instead, shouldn't we focus on fixing the root issue?!
In my system there is no /usr/lib/x86_64-linux-gnu/libfm
, so I understand why fish is complaining, but I cannot find how to remove this path from my $PATH
variable.
In the case of this question, why is this directory being erroneously added in the first place? Where is it being added? The best way (it seems to me) to remove a directory from the $PATH
variable is to prevent it from being added in the first place (clean up the broken glass) rather than attempting to fix it after-the-fact.
Finding where it was added can take a little debugging, but it shouldn't be too difficult. There are several places to look that I can think of:
System configuration
after some upgrade
The path being referenced is part of the PCMan File Manager, but I couldn't find any issues regarding its library directory being added to the path.
However, if it was a system upgrade that changed this, then start by looking at the system path:
sudo -e /etc/environment
If that's not it, then next check to see if the directory shows in the PATH
when running as root:
sudo -s
# Fish should be the $SHELL which was executed, but if not ...
fish
set --show PATH
If the bad directory is still present, then it is likely a system configuration issue. If not, then it's likely in the user configuration.
For system, of course, see if you can find a reference to the bad path somewhere in /etc
:
sudo grep -r libfm /etc
There's not much other than /etc/environment
that should impact Fish, but it's worth a check.
There shouldn't, as far as I know, be any Systemd units that impact this. Systemd doesn't (at the time of this answer) have the ability to set the user environment without some fairly extreme gymnastics (i.e. JSON user records, which just aren't used much yet). That said, at some point it may be worth checking a sudo grep -rs libfm /usr/lib/systemd
(the -s
suppresses messages on binary files matching).
User-level shell configuration
If it is user-level configuration, then check your user config, of course. I'd start with:
grep -r libfm ~/.config ~/.local
If needed, expand the search:
grep -r libfm ~
You could also substitute grep -r PATH ~
in there to look for any line changing the PATH
. It's possible that the libfm
directory could be part of another variable that is being used to change the PATH
.
Universal variable
Speaking of, there's always the chance that it is being added via $fish_user_paths
. However, there's a comment from the OP in one of the deleted answers here that indicates that was not the case here.
But for other readers, if it is the case, some of the above answers might be right! To check this, however, simply:
set --show fish_user_paths
If the bad directory is actually in there, then yes, simply remove it based on the index (best example in @ElijahLynn's answer). For instance, if $fish_user_paths[3]
is the erroneous path, then:
set --erase --universal fish_user_paths[3]
In the even smaller chance that it is some other variable being set and used in a PATH
modification:
set --show | grep libfm
Parent process environment
Finally, there's the chance that the parent process of your shell is modifying the environment before starting Fish. This would be rare for this type of issue, but it can certainly happen. pstree
and look for any common parent process of your shell. Typically, this will be login
, init
(WSL systems), systemd
itself, or something (not sure what it would be on macOS).
Use ps -o ppid -p $fish_pid
to get the parent process of your shell, then:
sudo -s
cat /proc/<pid>/environ
Is the erroneous path there? If so, then you'll need to determine why it is being set in that process (or one of its parents) to remove it.
grep -R /usr/lib/x86_64-linux-gnu/libfm ~/.config/fish /usr/share/fish
??