PATH changes

[Christiaan]

Hello...(very rusty)...I have XUbuntu:

I'd like to start apps easier from Terminal than having to navigate to different directories and then execute ie. "./ApplicationABC -PARA"...so IMHO I have to edit my PATH so that I can add directories to it and thus be able to execute "ApplicationABC -PARA" from my default Terminal home directory.

Thank you in advance for your patience...

 

[dos2unix]

This depends a little on which distro you're using.
What is the out of of...

set | grep PATH

Depending on which distro you're using, you might also try...

set | grep LOADABLES

Usually, the set command will have a PATH somewhere.
Usually it has /usr/bin:/usr/local/bin:/usr/sbin and a few others. Notice the directories are separated by a colon.

Edit your /home/user/.bashrc file.
It might look something like this. This isn't my complete .bashrc, but it contains the relevant parts.

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]; then
    PATH="$HOME/.local/bin:$HOME/bin:$PATH"
fi
export PATH

# Add new paths to PATH
export PATH="$PATH:/new/path1:/new/path2"

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

Right beneath the User specific paths, add any custom paths.
Note: You may have to logout and log back in for this to take effect.

 

[Christiaan]

Hello and thank you so much for responding...I note the amount of past answers/responses you have posted and appreciate you responding to my very mundane question!

My release/distro:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"

set | grep PATH
BASH_LOADABLES_PATH=/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
_=PATH
local PATH=$PATH:/sbin;
if [[ -z ${CDPATH:-} || $cur == ?(.)?(.)/* ]]; then
for i in ${CDPATH//:/'
PATH=$PATH:/usr/sbin:/sbin:/usr/local/sbin type $1 &> /dev/null
COMPREPLY=($(compgen -W "$(PATH="$PATH:/sbin" lsmod | awk '{if (NR != 1) print $1}')" -- "$1"))
local PATH=$PATH:/sbin;
local PATH="$PATH:/sbin:/usr/sbin";
COMPREPLY+=($(compgen -W "$(PATH="$PATH:/sbin" lspci -n | awk '{print $3}')" -- "$cur"))
local PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin;
COMPREPLY+=($(compgen -W "$(PATH="$PATH:/sbin" lsusb | awk '{print $6}')" -- "$cur"))


set | grep LOADABLES
BASH_LOADABLES_PATH=/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.

Now I also opened my .bashrc file and it contains no PATH setting at all...here is the full one:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
i) ;;
*) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands. Use like so:
# sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi

Thank you once again for your assistance here!

Kind Regards,
Christiaan

 

[dos2unix]

Try

grep -i path /home/username/.profile

Sometimes this is also name .bash_profile

If nothing else, you can try this.

cd ~
grep -i path .*

 

[Fanboi]

You'll find PATH is declared in .profile (and only ever should be). But do be aware that by default, .profile looks for local bin dirs first such as ~/.local/bin, ~/bin/ (depending on the distro's default setup for profile)*

Then each shell will have its own little rc file to setup further options. If you add PATH="$PATH:/home/dust/bin" to .bashrc (or equivalents), it will only affect bash logins...initially. When you open a subshell, that inherits PATH.

Anyway, it's fine to set PATH="$PATH:<whatever>" in the bash rc file (I presume you're on bash, most distros default to it, most users prefer it).

*That all said, I highly recommend you put local aliens in .local/lib/<app's dir>/ and link to the main executable in .local/bin/

Then you do not need to mess with PATH as the script in .profile searches /home/you/.local/bin/ and if it exists, adds it to PATH.

 

[dos2unix]

You'll find PATH is declared in .profile (and only ever should be).

Not for fedora/redhat. .bashrc is the default.

Some of us use multiple shells, zsh, csh, ksh, sh, etc...
.profile gets read by most (all?) of these. .bashrc only gets read by bash.

I have .cshrc and .kshrc files as well. The paths and other variables are different in these.

 

[JasKinasis]

Rather than adding a bunch of different directories to $PATH - it might make more sense to add a personal bin directory to your home directory.
Literally just run mkdir ~/bin/, add $HOME/bin to $PATH, then log out and log back in again to let the changes take effect. As @Fanboi said, some distros are already set up to check for the existence of a bin directory in $HOME and will add it to $PATH.
$HOME/.local/bin is another path that is commonly added - so that's potentially another one you might want to add. If the distro is already set up for a personal bin directory at either of those locations, you just need to create the directory and log out and back in again.

Whatever you choose: With a personal bin directory set up, you can put any personal scripts, or compiled executables that you have built from source into there and you can access them from anywhere in the filesystem. As long as the files in ~/bin are executable, you can run them as if they were a properly installed program.

Also you can put symbolic links to executables in other directories.
e.g.

ln -sT /path/to/executable linkName

Where /path/to/executable is the path to the executable you want to run and linkName is the name you want to give the symbolic link.
To run the program being pointed to you'd type linkName from anywhere in the system.

And sometimes a program you've downloaded might require you to be in a particular working directory in order for the executable to run, so you could also create a "wrapper" script in your personal bin directory which will cd into that directory, run the program and then cd back to the original directory.
e.g.
For urban terror I have a script called urt:

#!/usr/bin/env bash
cd ~/path/to/urban\ terror/
./urbanterror-executable
cd -

Note: I'm not at my Linux PC at the moment, I'm on my W11 work laptop, so the above isn't the exact script it's just the general jist of it:

• cd into the directory which contains the executable and all of its resources/dependencies.
• Run the executable
• cd back to the directory we were originally in.

Anyway, I hope that helps. It seems like you're already au-fait with changing $PATH, so I didn't include instructions on modifying $PATH. Also I've made several previous posts here about setting up a personal bin directory and cannot be bothered to repeat myself again (feel free to search 'personal bin directory' and my username and you should be able to find the other posts I've made on this topic).

But above are my brief tips for setting up and using a personal bin directory.

In a similar fashion, you can also set up a personal man directory and create and add your own man pages to document your own scripts.

 

[wizardfromoz]

Moving this to Command Line, it is not a Getting Started question.

Cheers

Chris Turner
wizardfromoz

 

[Christiaan]

It worked!! created the /bin in my personal directory and moved my executable there, logged-out/in and it worked!! )

Thank you once again for your patience and assistance.

Kind Regards,
Christiaan
===

My goodness, thank you so much for correct forum and the patient advice...much much appreciated...I'm going with @JasKinasis above then and getting going here...much much appreciated! Your willingness to assist is a breath of fresh air!

Kind Regards,
Christiaan

 

[Fanboi]

You'll find PATH is declared in .profile (and only ever should be).

Not for fedora/redhat. .bashrc is the default.

That's news to me. Honestly didn't notice... Interestingly, I just checked it out and .profile has lower priority with bash than bash_profile, .bash_login, whereas .bashrc is actually appended to the aforementioned during an interactive session -- separation of concerns, I guess.

Some of us use multiple shells, zsh, csh, ksh, sh, etc...
.profile gets read by most (all?) of these. .bashrc only gets read by bash.

I have .cshrc and .kshrc files as well. The paths and other variables are different in these.

I think you misread this part of my post...

You'll find PATH is declared in .profile (and only ever should be). [...]

Then each shell will have its own little rc file to setup further options. If you add PATH="$PATH:/home/dust/bin" to .bashrc (or equivalents), it will only affect bash logins...

^Agrees with you.

That said, csh, wouldn't be compatible with the syntax in .profile (.profile being essentially an Bourne-ish startup script). Over-generalization on both our parts, lol. The rest would AFAIK (how they prioritize is a different story entirely).

Well, for the sake of readers stumbling on this thread, there's something to learn: .profile was obviously intended to be the startup historically, then everyone went off and did their own things...
Maybe it even answers a question of why something in .profile doesn't affect a specific shell. Einstein said it best, "The more I learn, the more I realize I don't know."

 

[Trenix25]

See also: /etc/bash.bashrc

Signed,

Matthew Campbell