This question already has answers here:
where is $PATH set? Specifically where is my mac port path being set? [closed]
(2 answers)
Closed 6 years ago.
I used a program that set system setting and I can't find where my PATH environment variable was set, it's not set in:
.bashrc
.bash_profile
.profile
etc/paths
I have been trying to use a grep command:
grep -rl "PATH=" /
but the command is taking forever.
Does anyone have any suggestion on searching for where my PATH was assigned?
Run the following command:
PS4='+ $BASH_SOURCE:$LINENO:' BASH_XTRACEFD=7 bash -xlic "" 7>trace.out
Now, look through the file trace.out. It will show you everytime PATH was modified along with the file name and line number which caused the change.
Example
$ grep PATH trace.out
+ /etc/profile:7:PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
+ /etc/profile:9:export PATH
This tells you that line 7 of the file /etc/profile set the PATH.
How it works
The short story is that this starts up a bash login session with tracing turned on. For a longer explanation, see here.
Related
This question already has answers here:
How can I shortern my command line prompt's current directory?
(12 answers)
Closed 2 years ago.
When I am getting into my working directory, I have the next pathname in the console:
kravcneger#kravcneger-X751L:~/projects/gcc/my_project
That path is very long, and it increases the width of the terminal window.
How can I make the pathname shorter, so that I wouldn't have to expand the terminal for comfortable work?
A critical condition: to change the machine name and the working directory is prohibited. :)
Add (or change) in your ~/.bashrc file PS1 variable:
PS1='\h \W\$ '
Here, \h is the machine name, \W is the basename of the current directory, and \$ is the literal $.
SEE ALSO:
Controlling the Prompt (Bash Reference Manual)
This question already has an answer here:
Bash path variable using ~ resulting in 'No such file or directory'
(1 answer)
Closed 7 years ago.
In a bash script, I want the user to enter a path to an application, and then launch that application. By default, the application is expected to be in the user's own directory. The following script works for me on Mac OS X, but it is not particularly elegant:
path_default="~/neo4j/bin/neo4j"
read -p "Enter path to neo4j [$path_default]: " path
path="${path:-$path_default}"
if [[ ${path:0:1} == "~" ]]; then
path="/Users/$USER"${path#"~"}
fi
$path start
How can I improve this so that it will work on any platform?
if you consider ~ can be in any platform you can use a variable, for example userpath=$(echo ~)
Try this:
path_default="$HOME/bin/neo4j"
read -p "Enter path to neo4j [$path_default]: " path
path="${path:-$path_default}"
path="${path/#\~/$HOME}"
Here, tilde in the beginning of the path variable is substituted by the contents of $HOME variable.
This question already has answers here:
Why do you need ./ (dot-slash) before executable or script name to run it in bash?
(9 answers)
Closed 8 years ago.
As the question asked I thought "." means the current directory so why can't we directly type helloworld to run the program?
Because '.', the current directory, is not in your environment's $PATH, which contains the list of paths where executables get searched. To see your PATH variable, type
echo $PATH
This is most likely for security reasons, to prevent execution of local executables named after system or other trusted installed ones. I have worked on systems where '.' was in the PATH and at the very least it lead to some confusing moments (the test utility being a favourite candidate for accidental replacement.)
I would advise against appending '.' to PATH for those reasons.
This question already has answers here:
Why do you need ./ (dot-slash) before executable or script name to run it in bash?
(9 answers)
Closed 9 years ago.
To be more specific, what I mean is:
Suppose I have a python script called test.py with a proper shebang on the first line, say
#!/usr/bin/env python
print 'this works'
In the shell, when I type:
$ test.py
Nothing happens, but when I type:
$ ./test.py
The command is invoked and prints "this works".
Why is that? I thought "." just meant the current directory. Why would having a ./ suddenly mean we want to execute whatever comes next? Thanks.
The shell only looks for executables in the path (try echo $PATH in the shell to see its value). If . is not in the path, you'll have to give the explicit path to the executable. Not having . in the path is a good idea: imagine somebody managed to put an executable named ls in your home directory!
Because the current directory (where you had saved test.py) is not in your $PATH environment variable.
$PATH is searched for executables when you try to run one.
This question already has answers here:
What is the difference between these two commands which are used to run shell script?
(4 answers)
Closed 9 years ago.
I submitting some computations to the cluster and found out, that if I run my shell script that has qsub in it with . (note the space after the dot) instead of ./ the scope of some variable change and I don't have problems with library access, as I have with ./.
I know there have been questions about it before. 1 2
They discuss sh and . ./ method, however, and don't touch on .
Is . the same thing as . ./?
. cmd
vs
./cmd
are night and day different.
The first, is more like an "include", it executes the cmd within the context of the currently executing shell.
The second, is a path operation. ./cmd is akin to /usr/local/bin/cmd. the ./ is a path specifier.
In this case, it is saying that you are running a cmd in the current directory, rather than searching the PATH env variable for cmd.
When the cmd is executed, it is forked and exec'd in to it's own process, unrelated to the current process. A completely different result from the first example.
. is used to source a script.
The script will be run in the current shell, and any variables it sets will be available afterwards.
./ is a way of saying the 'current directory', and is just a path reference.