I am quite the novice and I messed something up awhile back. I do not know what I did, but now whenever I start up a new terminal I constantly have to export LIBRARY_PATH=/opt/local/lib. This is the default path for OSX I thought, and I think I might have voided it somehow.
It has just become so annoying to type that every time I want to run something like a gsl library, where are the default paths for bash on osx set? Thanks for any help you can offer.
You can add it to ~/.bash_profile
§ Invocation
When bash is invoked as an interactive login shell, or as a non-interactive shell
with the --login option, it first reads and executes commands from the file
/etc/profile, if that file exists. After reading that file, it looks for
~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and
executes commands from the first one that exists and is readable.
Related
I am trying to refresh my aliases on my Mac (OS Catalina 10.15.6) after defining new aliases in my .bash_profile file with the command:
source ~/.bash_profile
But terminal keeps giving this error message:-bash: s: command not found
This is confusing because for the longest time this command worked. I even had it included in my .bash_profile file as an alias, where it worked fine.
I'm aware the problem could have to do it with an error in my PATH but I've never made any edits to my PATH so have no idea what the issue could be?
Thanks in advance.
My first instinct would be to check both ~/.bashrc, and /etc/bashrc if it exists. That is where I customarily define aliases, and it looks to me as though a bad alias may be your problem.
I'm not saying it was the one you made, although it might be. Just go through your rc and profile files and look for any aliases which might in any way clash with source.
I suspect the source command is working just fine and the problem is a bad line in the ~/.bash_profile itself that looks like it's trying to run a command named s. I would look in there for the problem.
It might help to run it with xtrace on via bash -x ~/.bash_profile – running it in a separate process like that won't have any of the presumably-desired side effects of sourceing it in your current shell, but you can see what it's trying to do so that you can fix it.
(You can also just set -x before the source and get both xtrace and running in the current shell; just be sure to set +x afterwards or your shell session will be full of debug output.)
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I've used a number of different *nix-based systems of the years, and it seems like every flavor of Bash I use has a different algorithm for deciding which startup scripts to run. For the purposes of tasks like setting up environment variables and aliases and printing startup messages (e.g. MOTDs), which startup script is the appropriate place to do these?
What's the difference between putting things in .bashrc, .bash_profile, and .environment? I've also seen other files such as .login, .bash_login, and .profile; are these ever relevant? What are the differences in which ones get run when logging in physically, logging in remotely via ssh, and opening a new terminal window? Are there any significant differences across platforms (including Mac OS X (and its Terminal.app) and Cygwin Bash)?
The main difference with shell config files is that some are only read by "login" shells (eg. when you login from another host, or login at the text console of a local unix machine). these are the ones called, say, .login or .profile or .zlogin (depending on which shell you're using).
Then you have config files that are read by "interactive" shells (as in, ones connected to a terminal (or pseudo-terminal in the case of, say, a terminal emulator running under a windowing system). these are the ones with names like .bashrc, .tcshrc, .zshrc, etc.
bash complicates this in that .bashrc is only read by a shell that's both interactive and non-login, so you'll find most people end up telling their .bash_profile to also read .bashrc with something like
[[ -r ~/.bashrc ]] && . ~/.bashrc
Other shells behave differently - eg with zsh, .zshrc is always read for an interactive shell, whether it's a login one or not.
The manual page for bash explains the circumstances under which each file is read. Yes, behaviour is generally consistent between machines.
.profile is simply the login script filename originally used by /bin/sh. bash, being generally backwards-compatible with /bin/sh, will read .profile if one exists.
That's simple. It's explained in man bash:
/bin/bash
The bash executable
/etc/profile
The systemwide initialization file, executed for login shells
~/.bash_profile
The personal initialization file, executed for login shells
~/.bashrc
The individual per-interactive-shell startup file
~/.bash_logout
The individual login shell cleanup file, executed when a login shell exits
~/.inputrc
Individual readline initialization file
Login shells are the ones that are read one you login (so, they are not executed when merely starting up xterm, for example). There are other ways to login. For example using an X display manager. Those have other ways to read and export environment variables at login time.
Also read the INVOCATION chapter in the manual. It says "The following paragraphs describe how bash executes its startup files.", i think that's a spot-on :) It explains what an "interactive" shell is too.
Bash does not know about .environment. I suspect that's a file of your distribution, to set environment variables independent of the shell that you drive.
Classically, ~/.profile is used by Bourne Shell, and is probably supported by Bash as a legacy measure. Again, ~/.login and ~/.cshrc were used by C Shell - I'm not sure that Bash uses them at all.
The ~/.bash_profile would be used once, at login. The ~/.bashrc script is read every time a shell is started. This is analogous to /.cshrc for C Shell.
One consequence is that stuff in ~/.bashrc should be as lightweight (minimal) as possible to reduce the overhead when starting a non-login shell.
I believe the ~/.environment file is a compatibility file for Korn Shell.
I found information about .bashrc and .bash_profile here to sum it up:
.bash_profile is executed when you
login. Stuff you put in there might be
your PATH and other important
environment variables.
.bashrc is used for non login shells.
I'm not sure what that means. I know
that RedHat
executes it everytime you start
another shell (su to this user or
simply calling bash again) You might
want to put aliases in there but again
I am not sure what that means. I
simply ignore it myself.
.profile is the equivalent of
.bash_profile for the root. I think
the name is changed to let other
shells (csh, sh, tcsh) use it as well.
(you don't need one as a user)
There is also .bash_logout wich
executes at, yeah good guess...logout.
You might want to stop deamons or even
make a little housekeeping . You can
also add "clear" there if you want to
clear the screen when you log out.
Also there is a complete follow up on each of the configurations files here
These are probably even distro.-dependant, not all distros choose to have each configuraton with them and some have even more. But when they have the same name, they usualy include the same content.
According to Josh Staiger, Mac OS X's Terminal.app actually runs a login shell rather than a non-login shell by default for each new terminal window, calling .bash_profile instead of .bashrc.
He recommends:
Most of the time you don’t want to maintain two separate config files
for login and non-login shells — when you set a PATH, you want it to
apply to both. You can fix this by sourcing .bashrc from your
.bash_profile file, then putting PATH and common settings in .bashrc.
To do this, add the following lines to .bash_profile:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
Now when you login to your
machine from a console .bashrc will be called.
A good place to look at is the man page of bash. Here's an online version. Look for "INVOCATION" section.
I have used Debian-family distros which appear to execute .profile, but not .bash_profile,
whereas RHEL derivatives execute .bash_profile before .profile.
It seems to be a mess when you have to set up environment variables to work in any Linux OS.
I have added several aliases to my .zshrc file and they ONLY work if I restart terminal or use the source ~/.zshrc If I just open terminal, then type the alias, it will not recognize it, until I call source ~/.zshrc
So I know it's not a problem with the alias I created, I just have to load up the .zshrc file every time I want to use them.
What is going on? How can I fix this?
Well, you don't expect that you only have to edit a file and then, by magic, all your current zsh instances somehow ingest the changes, do you?
From the zsh man page, section STARTUP/SHUTDOWN FILES :
if the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc
($ZDOTDIR defaults to your $HOME). Hence, if you are in your terminal, you have three choices. Two of them you already found out (restart the terminal, source .zshrc manually). The third choice would be to just open a zsh subshell (by typing zsh).
Actually, there is a trick to do some "magic" in reading the file automatically: Zsh allows you to define a so-called precmd hook, which allows you to establish an arbitrary command to be executed just before a command prompt will be displayed. You could use it to source any file you like. If you want to use this feature, I strongly recommend against sourcing all of .zshrc. Sooner or later, you will have stuff in .zshrc that you don't want to be executed every time.
Instead, put your alias definitions into a separate file, say $HOME/.aliases, and in Zsh define the hook
function precmd {
source $HOME/.aliases
}
If you later change the .aliases file, you would still have to type a Carriage Return in your shell, in order to provoke a new prompt to be written and the precmd to be executed, but this is less cumbersome than sourcing the file manually.
I followed this answer to make a Python script, gn, in /opt/gn accessible via Terminal systemwide in Ubuntu like this:
PATH=${PATH}:/opt/gn
However, when I restart Terminal, I cannot longer execute the script system-wide. I have to retype the command from above.
I tried to copy that PATH to the last line of ~/.profile, but it would not work like that.
How to get permanent execution to a script?
In Ubuntu you can add additional search paths into /etc/environment.
Just append your path at the end of PATH="..." adding colon before your path.
After that you must re-login or reboot.
To get it permanent you need to store the updated path to a file that is read by your shell at startup. Try adding the path to your .bashrc-file?
See the INVOCATION-section in the man-page for bash
The part that applies to your question is
When an interactive shell that is not a login shell is started, bash reads and
executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist.
When bash is invoked as an interactive login shell, or as a non-interactive shell
with the --login option, it first reads and executes commands from the file
/etc/profile, if that file exists. After reading that file, it looks for
~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and exe‐
cutes commands from the first one that exists and is readable.
meaning that you simply put your updated path in the wrong file.
I have the following lines in my .bashrc which I would like to get executed upon logging in through ssh.
csh
source /x/y/.cshrc
source /x/y/z/sourceme
But the problem is that only the first command is being executed correctly.
(csh prompt is coming up)
The following source command is not effected.
I noticed that there are some errors which are thrown from bash (not csh) for the 'source' command
I read somewhere that this may be due to .bashrc getting executed multiple times. And source commands trying to get executed in bash itself rather than csh.
I want all the three commands to be executed one after other upon log-in. how can I do that? I tried .bash_profile .bash_login etc. Also I don't have write access to /etc/profile
The "commands" are interpreted by the bash shell. They aren't bytes to be fed to the terminal. What happens is that csh runs interactively, and once it exits bash will source the two (presumably csh) script files.
It looks like you're simply trying to change your shell to csh (why, I have no idea). Have you tried using chsh for that?
If you want to run these commands in csh, move them to your .cshrc.
A word of caution, though; using csh for absolutely anything raises the question, do you really think you know what you are doing? Why?
source is a "bashism", that is to say it won't work in other shells. Use . instead.