I have added the following:
export SQOOP_HOME=/usr/bin/
to my /etc/profile file. However when I run an install.sh script it keeps saying the environment variable is not set. I have also added similar lines to the bash_profile.
Any ideas what I could be doing wrong?
When running a shell script, it runs (by default) non-login and non-interactive--see my answer to another question on Unix.SE for a rundown of when and where bash looks for config files. You will probably want to add the -l option to the shebang line to make it a login shell.
You need to do a login before you can see the changes in /etc/profile. Try:
bash -l
for example.
Related
I could not find the my bash profile which running automatically after login.
I already checked /home/(username) with ls -a.
I am sure there is bash profile because when i echo $somethings, it response.
Could you help me ?
Check for ~/.bash_profile, ~/.bash_login, ~/.profile or even maybe ~/.bashrc, which isn't a "profile", but might be run after login (see INVOCATION in man bash to understand when and in what order bash reads its startup files). If the file doesn't exist, you can create it.
There're also the system-wide /etc/profile and /etc/bash.bashrc.
After /etc/profile, the bash shell (assuming it's either an interactive login shell or run with the --login option) looks for the first file in this set (in your home directory) that exists and is readable:
~/.bash_profile;
~/.bash_login; and
~/.profile.
Hence you may not even have a .bash_profile.
The rules are actually very complex, depending on the type of the shell and the various arguments you give to it. If you want to know in detail, have a look in the INVOCATION section of the bash man page.
I have studio.sh file in my android-studio/bin folder, which I would like to use as a command in bash (like launching any other normal application).
I read somewhere that adding this line to ~/.profile should work,
export PATH=$PATH:/home/goel/android-studio/bin
But it doesn't work. Whats the correct process?
Add the script folder name to PATH environment variable in ~/bash.rc file
and you can also create alias for you script in ~/bash.rc
and source the /etc/bash.bashrc file, now you can issue your script or alias name in any terminal. Hope this helps.
If you change your PATH in a .profile, you still have to make the shell read the .profile. Starting a new terminal is sometimes not enough (some terminals don't read the .profile), in which case you have to log out and back in.
Is studio.sh executable? Have you tried ./studio.sh inside its containing folder to check whether it runs at all?
I have added entries such as the following in my /etc/bashrc (on Fedora).
#=========== Maven Related variables
export JAVA_HOME='/usr/java/default'
export PATH=${JAVA_HOME}:$PATH
#=========== Maven Related variables
export M2_HOME=/usr/local/apache-maven/apache-maven-3.0.4
export PATH=${M2_HOME}/bin:$PATH
#=========== Ant Related variables
export ANT_HOME=/usr/local/apache-ant
export Path=${ANT_HOME}/bin:$PATH
Now, each time that I execute bash command to refresh the environment variables, all these additions are repeated, and the PATH just keep adding itself recursively; if I keep doing bash for a few dozen times, then the $PATH becomes a hundred lines of repeating content. What am I doing wrong?
Note that I have added these entries to /etc/bashrc since I want to have these values in PATH no matter what user I login as.
Thanks,
Shannon
Don't set your PATH incrementally in .bashrc; set it once in .profile and leave it alone thereafter. Or, since you mention /etc/bashrc, don't set the PATH incrementally in /etc/bashrc; set it once in /etc/profile and leave it alone.
One side-benefit; things will work a little faster.
See also the code in How do I manipulate PATH elements in shell scripts for code to clean up a repetitive PATH.
If by this statement:
... execute bash command to refresh the environment variables ...
you mean that you are entering the command
bash
at the command prompt, you are not "refreshing the environment variables". You are launching a new subshell of the current shell. The new shell inherits the path of the original shell, to which you are once again making additions. Each time you do this the PATH will get longer.
You can use something like:
PATH=$(echo "$PATH" | awk -v RS=: -v ORS=: '!(a[$0]++)' | sed 's/:$//')
to clean up your path after changing it. Also, since the the first match is used when scanning the path, having duplicates doesn't really matter.
I had also faced the same problem (CentOS). This is how I fixed it.
Added the following lines to my user's .profile
export PATH=/usr/local/apache-maven-3.3.3/bin:$PATH
export JAVA_HOME=/usr
export SHELL=/bin/bash
# to run bash (because ksh was my default shell)
/bin/bash
No changes to my user's .bashrc file
No changes to /etc/profile
No changes to /etc/bashrc
I'm using knoppix 7.0.3 and trying to set the PATH environment variable. According to the official Ubuntu documentation, /etc/environment should be the preferred place for this. So I added these lines in the file:
JAVA_HOME="/usr/lib/jvm/java-6-sun"
GRAILS_HOME="/home/knoppix/grails"
PATH="${PATH}:${JAVA_HOME}/bin:${GRAILS_HOME}/bin"
But after rebooting the system, the file just reverted to the original one (I was using persistent storage).
Then after some Googling, I tried to edit ~/.profile like this:
export JAVA_HOME="/usr/lib/jvm/java-6-sun"
export GRAILS_HOME="/home/knoppix/grails"
export PATH=$PATH:$JAVA_HOME/bin:$GRAILS_HOME/bin
This time, the first two variables got set (echoed in console), but the PATH didn't. It was still the default one when I echoed. What's wrong?
Modify /etc/profile on the following line:
PATH=".:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
The problem is that your PATH is being overwritten during initialization of bash, after reading .profile.
From the manpage of bash:
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. The --noprofile option may be used when the shell is started to inhibit this behavior.
...
When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.
From your experience, it is apparent that if .bashrc doesn't exist, bash is trying to set PATH to a default value (I would appreciate if someone confirms this).
As we discussed in the comments on your question, adding the export commands to .bashrc (and thus creating the file) solves the problem. Alternatively, you can add
source ~/.profile
to the end of your .bashrc file for the same effect.
I've been editing .bashrc files and other init files, and it seems that I've left behind a few code snippets or two that are causing a few errors at the prompt (e.g. file missing), but I can't find them.
How do I debug the prompt to find out what init scripts I've carelessly hacked?
Most of the shells have debug flags that show the commands being executed. Bash may even have one that shows a command before expansion of variables and after. Have you tried checking (I believe) -c -x or -X flags and see if they show the information you are looking for.
You can set them as first thing in the rc files (most global one) or just pass it down into bash command by invoking it from another shell.
In fact, if you invoke bash from another shell, you can also use script command to record everything you see and do into the file, which makes postmortem analysis so much easier.
Try invoking bash with the -x flag, then sourcing your .bashrc or .bash_profile or whatever you're using. That ought to be prolix enough to find your problem
ie:
bash -x
source .bashrc
The easiest way to get a clean initial state is to SSH into your current host, but instead of letting SSH launch your shell with default settings, you provide an explicit command which prevents .bashrc from being read.
ssh -tt localhost /bin/bash --norc
The -tt forces SSH to allocate a TTY, which is what would normally happen when you open a shell connection, but is not default when running an explicit command.
The --norc prevents bash from reading your settings file (since we want to do that ourselves).
You should now be at a bash prompt, in a clean environment. This is useful for examining what variable are set to before your .bashrc runs etc. Enable tracing and source your .bashrc:
set -x # Enable tracing
source .bashrc
Try to see where you've defined prompt - probably it in some dot file in your home directory:
grep PS1 ~/.*
You can see current value of prompt by just printing it:
echo $PS1
HTH
Check the .bash_history file in your home directory to find out what commands you have been running. If you used commands like vi filename to open the init scripts, it will find them in the command history.