Replace $PATH with string/file? Set $PATH to null and append?-CodePudding

Backup, first.

Before attempting to resolve this, people are worried about $PATH changes breaking things. Backup your path with echo $PATH > $HOME/bak/conf/path.bak and remember (don't put any raw files into the bak dir). Confirm your backup with cat $HOME/bak/conf/path.bak.

A minimal $PATH!

My desired path is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin.
This is a minimalist path that should break nothing on most default Linux installs (Backup, first).

I have a huge $PATH that is completely useless (like 120 lines of $PATH--caused by WSL [more later]). So far, I only know how to add to path and remove single directories from $PATH via seg.

Sounds like it should pop right up on search engines. I have a headache in my eye--: how do I set $PATH to a raw string or purge it so I can append from null?.

Bonus points for anyone who can tell me how to set $PATH from the contents of a file!?

Best guess:

import sys, sys.path.insert(0, '/your/path')--!NO This did not work!

Temporary workaround:

You can move the path to a neutral file (or use whatever means you know) and replace / with / and then use sed to cut the unwanted part out:

PATH=$(echo "$PATH" | sed -e 's/:\/tons:\/of:\/unwanted:\/garbage$//') Make sure you put everything you don't want between s/ and $//').

Where is this long $PATH coming from?

Related question: How to remove the Win10's PATH from WSL --$PATH is inherited every time you re-launch or perform some other actions such as possibly changing users or environments.

Why is this question different:

As if there isn't enough typing, S.O. has a nuisance dialog that asks me to write and explain why purging $PATH is different from removing one directory/path from $PATH.

Because a punch in the face isn't a kick in the butt.

CodePudding user response：

If I'm understanding your question, you simply want to know how to set your Bash PATH to a fixed string (or erase it completely) and have it persist across restarts of the shell?

If so, then I'll start off by saying that this isn't recommended as it will break other things. If not now, then later.

But if you really want to set the PATH to a fixed value every time Bash starts ...

Short answer first:

Assuming fairly "default" startup files (where ~/.profile sources ~/.bashrc):

Edit your ~/.profile (or ~/.bash_profile in the rare case it exists) and add:
```
# Remove entirely
unset PATH
export -n PATH

# Optionally
export PATH=/new/pathItem1:/new/path/Item2
```
Adding this to the bottom of the file should override any other PATH modifications done previously. However, future application installations can make modifications below that, therefore overriding it.
In a very rare case where you have an interactive Bash session that isn't startup by a login shell, you could also make the same modifications to ~/.bashrc.
(Not necessarily required if the modification is the last thing called during startup, but) make sure that there are no other PATH adjustments in your ~/.bashrc or ~/.bash_profile.

More explanation:

Where is this long $PATH coming from?

Your path in Bash in WSL can potentially come from a few sources:

WSL's init process sets a default PATH for the starting application (shell). This is currently (in WSL 0.70.8):

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib

Since this is done before your ~/.profile runs, there's no need to worry about disabling it.
As you've pointed out, WSL automatically appends the Windows path to the Linux path so that you can launch Windows executables. This can be disabled using the method in the question you linked, but it's not necessary if you simply want to override the entire PATH. Setting the PATH in your ~/.profile comes after WSL sets it for the initial process (your shell).
Bash itself has a built-in, default path that is hardcoded into it for "fallback" in case no other path is passed in. This rarely ever takes effect. Most Linux systems are going to set the PATH through some other mechanism, meaning the fallback never gets activated. A typical Linux system will set the default PATH via /etc/environment, but this isn't used under WSL since the init mechanism mentioned above is needed instead.
If using Systemd or another init system in WSL, then Bash (and other POSIX shells) will process /etc/profile and files in /etc/profile.d when starting. These files may contain PATH modifications. Again, since these come before your ~/.profile, (re)setting the PATH to a fixed value will override any of these settings.
Finally, your ~/.profile or ~/.bash_profile (for login shells) and ~/.bashrc (for interactive shells are read. Typically, PATH modifications in these files look something like:
```
export PATH="/new/path/item:$PATH"
```
This prepends to the path, making that new item take priority over the previous items.

However, leaving out the existing :$PATH part will simply set it to a string literal.

It should be obvious, but if you do this without including the "normal" OS paths, you will be unable to call any command that isn't built in to Bash already with specifying its fully qualified path. For instance, ls will fail. Note that you can still:

$ ls
ls: command not found
$ /usr/bin/ls
# works

Also note that ~/.profile is called for login shells. It is possible, however, to tell WSL to launch Bash without reading ~/.profile:

wsl ~ -e bash --noprofile

The resulting shell will still have the default WSL path in this case.