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.
Related
This question already has answers here:
Difference between single and double quotes in Bash
(7 answers)
Closed 2 years ago.
I have an alias in bashrc that I use to generate a particular LaTeX document (the main command used is pdflatex) but I want to be able to execute it regardless of where I am. Unfortunately, it seems like you can't use use this command with an absolute path unless the path is 'under' your current directory, so I cd into the directory my .tex file is, run pdflatex, then try to cd back to my previous directory. In bashrc, I have my command as
alias nbr="cd ~/path/to/dir && pdflatex file.tex && cd $OLDPWD"
The command works fine outside of putting me back in my previous directory. For some reason, this command works perfectly fine in a regular bash shell, so I'm guessing there's some issue with what $OLDPWD is considered in the context of bashrc but I'm not sure. Any ideas?
#Cyrus's answer fixed it...should've used single quotes.
This question already has answers here:
Shell script current directory?
(7 answers)
Closed 2 years ago.
I want to be able to execute a bash script located in my home directory with the command ~/script_name.sh from any directory and then in the script, get the directory that it was ran from.
eg. I'm in the directory /foo/bar/baz, and execute /foo/script.sh, and it prints out /foo/bar/baz
pwd and $0/$BASH_SOURCE give me the directory my shell starts in and the path to the script in my home directory respectively.
Instead of invoking the external command pwd, consider using $PWD instead. If you want to protect against some rogue code having explicitly changed PWD, do a cd . (which is an internal command) first, which restores PWD to the correct value.
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 4 years ago.
Our class on unix had an a question I did not know the answer to.
"why is it necessary to use ./XXX.sh to execute a bash executable?". I have not been able to find the answer on the web or in our textbook.
When you are invoking a command, the shell looks for the command in your $PATH variable, it will not look into your current directory. So you have to specifically tell the shell where your command is located. In this case, when the command or script is located in your current directory ., you need to invoke it using ./XXX.sh. In fact you can invoke scripts not inside your current directory using its full path e.g. /some/path/XXX.sh or relative to your current working directory e.g. ../../some/path/XXX.sh
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 5 years ago.
When I executeinit-hooks I get
bash: init-hooks: command-not found
here are the contents of init-hooks:
#!/bin/bash
set -e
printf '\ncopying hooks\n\n'
cp ./hooks/* ../../.git/hooks
When I execute cp ./hooks/* ../../.git/hooks from bash directly execution is successful.
(note this is the same command as what is in the script)
Proof of the files are in the directory and the results of execution:
Why does my script behave differently than the command/why is my script not found?
On the Linux systems (where bash comes from) the current directory is usually not included in the path for security reasons.
Run echo $PATH to check what directories are used to search for executables when they are provided in the command line without a path. The current directory (.) should not be there.
Run the script as ./init-hooks and bash will find it.
I suugest to run it following way
./init_hooks
or put fully qualified file name.
make sure to make the script executable
chmod +x ./init_hooks
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.