I would like to know if there is a way to determine where a specific part of my $PATH variable is being set.

About a year and and a half ago I went through the tedious process of setting up a Oracle XE 11.2.0 on my machine for a course I was taking. Somewhere in the process I added the path "/u01/app/oracle/product/11.2.0/xe/bin" to my $PATH variable to get things working. Well now I've deleted the root /u01/ folder that was exclusively used by the Oracle DB and so bash throws the error on startup that the file or directory doesn't exist. So I went manually looking through every possible file I can find listed and nothing.

As far as I can tell, that part of $PATH is not being set in any of these files: /etc/login.defs, ~/.profile, /etc/environment, /etc/profile, ~/.bash_login, ~/.bash_profile or ~/.bashrc.

That was verified first by running cat ~/.bashrc | grep "*oracle*" on every file listed above. I even did the insane thing and ran sudo strings /dev/sdb -n 11 | grep -C100 "/u01/app/oracle/*" to give me a list of every file that contained the string. I got lots of results, but nothing super valuable. My poor SSD didn't deserve that.

So any tips? How can I find out where that part of $PATH is being concatenated onto? Are there any other typical files that I should check? I'm running this on Linux Mint 18.3 if that narrows anything down.

  • Doesn't "echo $PATH" give you all the paths? – Raman Sailopal Jul 23 '18 at 8:53
  • I think OP know all component of $PATH, but want to know which shell snippet add "/u01/app/oracle/product/11.2.0/xe/bin" in it. .bashrc ? .profile ? .foo/bar/oracle.rc ? – Archemar Jul 23 '18 at 8:56
  • grep uses regular expressions, not wildcards. *oracle* doesn't mean what you think it does in regex. Just do grep oracle ~/.bashrc ~/.profile (and whichever other files you want to grep). – muru Jul 23 '18 at 8:57
  • @muru Thanks for pointing this flaw out, but running with just grep oracle on any of the above files listed stills pulls up nothing. – Aaron Chamberlain Jul 23 '18 at 9:17
  • 1
    Try PS4=' $BASH_SOURCE:$LINENO: ' bash -lixc true |& grep oracle. – muru Jul 23 '18 at 9:19

One way to debug shell initialization would be to run a login, interactive shell (-li) and tell it to print all commands as they're executed, and look for what you want in the output:

PS4=' $BASH_SOURCE:$LINENO: ' bash -lixc true |& grep oracle

PS4 is use by bash for printing the extra information from the -x option, and when set to $BASH_SOURCE:$LINENO, it will print the path to the file being sourced and the line number being executed. Running with -c true |& grep oracle allows us to filter the initialization of a single shell quickly. With the leading space, bash intends lines when nested sourcing takes place.

| improve this answer | |


grep -lr /u01/app/oracle/product/11.2.0/xe/bin /etc/*

This lists files in /etc/ containing the path element. If like you said it's not in the files you listed in the question, it should be below /etc/. My guess would be some file in /etc/profile.d/ .

Update 1

Assuming you use bash, you could try bash -v or bash -x to try see what commands are run. bash -v dumps the original source, bash -x dumps the actually executed commands with expanded variables. The flags can be combined, at the cost of becoming a lot less readable :)

| improve this answer | |

You might also check for string oraenv.

Oracle database installer typically creates a pair of scripts: /usr/local/bin/oraenv to set all the environment variables required by the Oracle database engine, and /usr/local/bin/coraenv to unset them. Since these scripts aim to manipulate the environment variables of the current session, they need to be "sourced" or they won't have the expected effect.

You might have included oraenv in your login scripts like this:

ORACLE_SID=<database SID here>
. oraenv

The last line could also be source oraenv.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.