I'm working on installing the flow-project and I'm getting a message to add some things into my bashrc. Not sure if it matters but I'm on macOS.
This is the message it reads: https://i.stack.imgur.com/EbP3j.png
~/flow
Add the following to your ~/.bashrc:
export SUMO_HOME="$HOME/sumo_binaries/bin"
export PATH="$SUMO_HOME:$PATH"
I've looked in other threads too, I've added it manually as well as the "echo >> ~/.bashrc" method. It's definitely in the txt file. Thanks!
Edit: Question wasn't made clear, but I have tried putting the export ... into my .bashrc file but the thing I'm trying to install doesn't recognize that I've done that.
Verify what's exported with:
export -p
as per help
export: export [-nf] [name[=value] ...] or export -p
NAMEs are marked for automatic export to the environment of
subsequently executed commands. If the -f option is given,
the NAMEs refer to functions. If no NAMEs are given, or if `-p'
is given, a list of all names that are exported in this shell is
printed. An argument of `-n' says to remove the export property
from subsequent NAMEs. An argument of `--' disables further option
processing.
Related
I'm using zsh terminal, and I'm trying to add a new entry (/home/david/pear/bin) to the PATH variable. I don't see a reference to the PATH variable in my ~/.zshrc file, but doing echo $PATH returns:
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
So I know that the path variable is being set somewhere. Where is the PATH variable set / modified for the zsh terminal?
Actually, using ZSH allows you to use special mapping of environment variables. So you can simply do:
# append
path+=('/home/david/pear/bin')
# or prepend
path=('/home/david/pear/bin' $path)
# export to sub-processes (make it inherited by child processes)
export PATH
For me that's a very neat feature which can be propagated to other variables.
Example:
typeset -T LD_LIBRARY_PATH ld_library_path :
Here, add this line to .zshrc:
export PATH=/home/david/pear/bin:$PATH
EDIT: This does work, but ony's answer above is better, as it takes advantage of the structured interface ZSH provides for variables like $PATH. This approach is standard for bash, but as far as I know, there is no reason to use it when ZSH provides better alternatives.
You can append to your PATH in a minimal fashion. No need for
parentheses unless you're appending more than one element. It also
usually doesn't need quotes. So the simple, short way to append is:
path+=/some/new/bin/dir
This lower-case syntax is using path as an array, yet also
affects its upper-case partner equivalent, PATH (to which it is
"bound" via typeset).
(Notice that no : is needed/wanted as a separator.)
Common interactive usage
Then the common pattern for testing a new script/executable becomes:
path+=$PWD/.
# or
path+=$PWD/bin
Common config usage
You can sprinkle path settings around your .zshrc (as above) and it will naturally lead to the earlier listed settings taking precedence (though you may occasionally still want to use the "prepend" form path=(/some/new/bin/dir $path)).
Related tidbits
Treating path this way (as an array) also means: no need to do a
rehash to get the newly pathed commands to be found.
Also take a look at vared path as a dynamic way to edit path
(and other things).
You may only be interested in path for this question, but since
we're talking about exports and arrays, note that
arrays generally cannot be exported.
You can even prevent PATH from taking on duplicate entries
(refer to
this
and this):
typeset -U path
PATH pre-populated
The reason your path already has some entries in it is due to your system shell files setting path for you. This is covered in a couple other posts:
Why and where the $PATH env variable is set?
Where is the source of $PATH? I cannot find it in .zshrc
one liner, without opening ~/.zshrc file
echo -n 'export PATH=~/bin:$PATH' >> ~/.zshrc
or
echo -n 'export PATH=$HOME/bin:$PATH' >> ~/.zshrc
To see the effect, do source ~/.zshrc in the same tab or open a new tab
Added path to ~/.zshrc
sudo vi ~/.zshrc
add new path
export PATH="$PATH:[NEW_DIRECTORY]/bin"
Update ~/.zshrc
Save ~/.zshrc
source ~/.zshrc
Check PATH
echo $PATH
OPTION 1: Add this line to ~/.zshrc:
export "PATH=$HOME/pear/bin:$PATH"
After that you need to run source ~/.zshrc in order your changes to take affect OR close this window and open a new one
OPTION 2: execute it inside the terminal console to add this path only to the current terminal window session. When you close the window/session, it will be lost.
If you are on macOS (I'm on Monterey 12.3.1), you may have been pulling your hair like I did metaphorically. These instructions above all worked for me within the terminal session, but I could never get it to persist no matter what I did with export. Moreover, I couldn't find the .zshrc anywhere.
Turns out Apple does it differently. The file you need to edit is etc/paths. You can simply sudo nano /etc/paths and add your path in a new line. Then simply restart terminal and voila.
for me PATH=$PATH:/path/to/file/bin
then export PATH worked.
to check echo $PATH . other solutions are adding the path temporarily.
I'm on Monterey 12.4 and the only way I could change the path was using the helper function. Editing text files in nano did diddly squat
# append
path+=('/foo/bar/yourpath')
# export to sub-processes
export PATH
to verify your new directory has been added correctly, you can use
print -l $path
thanks to the fact that its type is known to be an array
how to append new plugin to zshrc file. I tried the below syntax but it replaced with new one.
sed -i -e 's/plugins=(.*)/plugins=(zsh-syntax-highlighting)/' ~/.zshrc
I want to add git, file, docker etc.
pl give me the corrected syntax.
KSK
My bash_profile as follows:
export PATH+=":/Users/steve/workspace/bash-tools/misc";
when I use
source ~/.bash_profile
it said
/Users/style/.bash_profile:export:2: not valid in this context: PATH+
I searched on Google but found nothing, please help
zsh's export command doesn't support the += operator, just =. The standard way to do this is to explicitly include the old PATH value:
export PATH="$PATH:/Users/steve/workspace/bash-tools/misc"
...but there's another problem. You said this was in your bash_profile, and that's explicitly a bash init file, not zsh. If you want setup to be shared between both bash and zsh, I'd recommend doing something like putting the actual setup code in ~/.profile (which is the generic startup file for POSIX login shells), and then sourceing it from separate ~/.zprofile and ~/.bash_profile files, like this:
[ -f ~/.profile ] || source ~/.profile
This way, you can also add zsh-only setup in the ~/.zprofile file, bash-only setup in the ~/.bash_profile file, and still have them share most of the setup.
On the other hand, if you only use zsh, then just put it in ~/.zprofile.
Given below are the contents of my /etc/environment file
alias ...="cd ../../"
alias ls="ls -al"
export blah="blah blah"
When I start new terminal session and change to sudo user as sudo su, only the export command has run, which I am able to verify using env. The aliases are not set.
If I run source /etc/environment the aliases get set as expected. Am I missing something? I also read that /etc/environment is only read when the system boots. Is that true?
I am running on RHEL 7.
The /etc/environment is intended for setting environment variables for every user on login. Therefore you don't need to use export in this file.
Adding alias into this file won't work, because this file is not a shell script and only accepts variable=value pairs.
/etc/environment is used by the PAM-env module and is agnostic to
login/non-login, interactive/non-interactive and also Bash/non-Bash,
so scripting or glob expansion cannot be used. The file only accepts
variable=value pairs.
It's not possible to export aliases or set them globally - they need to be set again in every shell instance.
The file you want to use is ~/.bashrc in a home directory of a user. This file gets executed every time a user opens a bash shell. So aliases and variables set in this file will have effect only on that shell.
You can also use /etc/bash.bashrc which is System-wide .bashrc file for interactive bash shells.
The reason why the export in your /etc/environment worked and actually created and env variable is that the pam-env parser specifically ignores export keyword to avoid confusion for people who don't know that /etc/environment is not a shell script.
You can see that in pam_env.c source code
/* skip over "export " if present so we can be compat with
bash type declarations */
if (strncmp(key, "export ", (size_t) 7) == 0)
key += 7;
Its available for example here - Linux-PAM/pam_env.c v0.79. See line 00234.
If I set a variable using export and then get out of the command line and go back to it, it no longer has that value. This is because export only works for subprocesses but not for parent processes. How can I get export to make the value permanent?
You can add the export in the file $HOME/.bash_profile and then run the following command:
source $HOME/.bash_profile
I have this in .bashrc;
PS1='$'
However, I see this still in terminal:
mas-macbook:some/path mas$
I want
$
PS1 should already have been exported long before you get to your .bashrc file, at least for a login shell. In that case, setting PS1 should simply overwrite the value (not its export status).
One thing to keep in mind is that bash itself does not run your .bashrc file for a login shell. The actual sequence of execution is:
/etc/profile, if there.
first of ~/.bash_profile, ~/.bash_login or ~/.profile.
I'm fairly certain that, if you want .bashrc to run for a login shell, it has to be sourced from one of those above.
For example, /etc/profile may call /etc/profile.local or all the scripts in the /etc/profile.d/ directory. Similarly, my .bash_profile calls the following, if they exist:
/etc/bash.bashrc
~/.bashrc
with the following snippet:
if [ -e /etc/bash.bashrc ] ; then
source /etc/bash.bashrc
fi
if [ -e "${HOME}/.bashrc" ] ; then
source "${HOME}/.bashrc"
fi
When I change PS1 and echo "hello" in my .bashrc, but comment out the sourcing of it in .bash_profile, the prompt doesn't get changed (nor the string printed) when I log in. When I uncomment the sourcing, I get both the string printed and the prompt changed when I log in.
To make sure that your .bashrc is called for your login shells, put that echo hello statement just after setting PS1, then log in to check.
If it is being called when you log in, you can execute "export -p" from your shell to get a list of all the exported variables - make sure PS1 has a "declare -x" in front of it. If not, just change your .bashrc to export it as well:
export PS1='$'
If it's already exported, then something is changing it after your set statement. In that case, you'll need to actually look at the login execution path to see what's getting called before it gives you control.
I think you need the export keyword:
export PS1='$'
You may have to escape the $ symbol. This works in my system...
PS1="\$"
If that don't work, please run the command 'echo $PS1' and let us know the results. You may also have to send the .bashrc file - it possible that you have set the PS1 variable before including the global /etc/bashrc file. If that's the case, the global file will overwrite the variable. You will have to set the PS1 variable after including the /etc/bashrc file.