File Execution with Dot Space Versus Dot Slash

File execution with dot space versus dot slash

Let's start with how the command path works and when it's used. When you run a command like:

ls /tmp

The ls here doesn't contain a / character, so the shell searches the directories in your command path (the value of the PATH environment variable) for a file named ls. If it finds one, it executes that file. In the case of ls, it's usually in /bin or /usr/bin, and both of those directories are typically in your path.

When you issue a command with a / in the command word:

/bin/ls /tmp

The shell doesn't search the command path. It looks specifically for the file /bin/ls and executes that.

Running ./A is an example of running a command with a / in its name. The shell doesn't search the command path; it looks specifically for the file named ./A and executes that. "." is shorthand for your current working directory, so ./A refers to a file that ought to be in your current working directory. If the file exists, it's run like any other command. For example:

cd /bin
./ls

would work to run /bin/ls.

Running . A is an example of sourcing a file. The file being sourced must be a text file containing shell commands. It is executed by the current shell, without starting a new process. The file to be sourced is found in the same way that commands are found. If the name of the file contains a /, then the shell reads the specific file that you named. If the name of the file doesn't contain a /, then the shell looks for it in the command path.

. A        # Looks for A using the command path, so might source /bin/A for example
. ./A # Specifically sources ./A

So, your script tries to execute . B and fails claiming that B doesn't exist, even though there's a file named B right there in your current directory. As discussed above, the shell would have searched your command path for B because B didn't contain any / characters. When searching for a command, the shell doesn't automatically search the current directory. It only searches the current directory if that directory is part of the command path.

In short, . B is probably failing because you don't have "." (current directory) in your command path, and the script which is trying to source B is assuming that "." is part of your path. In my opinion, this is a bug in the script. Lots of people run without "." in their path, and the script shouldn't depend on that.

Edit:

You say the script uses ksh, while you are using bash. Ksh follows the POSIX standard--actually, KSH was the basis for the POSIX standard--and always searches the command path as I described. Bash has a flag called "POSIX mode" which controls how strictly it follows the POSIX standard. When not in POSIX mode--which is how people generally use it--bash will check the current directory for the file to be sourced if it doesn't find the file in the command path.

If you were to run bash -posix and run . B within that bash instance, you should find that it won't work.

Why do you need ./ (dot-slash) before executable or script name to run it in bash?

Because on Unix, usually, the current directory is not in $PATH.

When you type a command the shell looks up a list of directories, as specified by the PATH variable. The current directory is not in that list.

The reason for not having the current directory on that list is security.

Let's say you're root and go into another user's directory and type sl instead of ls. If the current directory is in PATH, the shell will try to execute the sl program in that directory (since there is no other sl program). That sl program might be malicious.

It works with ./ because POSIX specifies that a command name that contain a / will be used as a filename directly, suppressing a search in $PATH. You could have used full path for the exact same effect, but ./ is shorter and easier to write.

EDIT

That sl part was just an example. The directories in PATH are searched sequentially and when a match is made that program is executed. So, depending on how PATH looks, typing a normal command may or may not be enough to run the program in the current directory.

What does ./ (dot slash) refer to in terms of an HTML file path location?

./ is the the folder that the working file is in:

So in /index.htm ./ is the root directory

but in /css/style.css ./ is the css folder.

This is important to remember because if you move CSS from /index.htm to /css/style.css the path will change.

Why do I need to put dot forward slash when running a 'sh' command in Linux?

Please check http://www.linfo.org/dot_slash.html as well.
Basically this is a safety mechanism to indicate the program to execute is in the current directory and NOT a built-in command, a command in some other folder specified in the PATH etc.

From the link:

Files in the current directory can be accessed for reading and writing by merely entering the command name (e.g., cat or vi) followed by the name of the file. That is, no absolute path is necessary. However, when execution is desired, either an absolute path (or its dot slash equivalent) or the inclusion of the directory containing the command's executable file in the PATH variable is necessary. This is a built-in safety mechanism.

If your script is running without ./ then it means the specific location is in the path or . is in the path as mentioned in comments.

Hope it helps.

Running shell scripts with ./ dot-slash

The null-pointer exceptions are coming from your Java program, so they mean that the process was, in fact, started. They do not, as a rule, indicate a problem with your shell script or its invocation.

. something # this reads the file `something`, running each line as a command
# in your current shell. (Actual behavior is a bit more sophisticated
# than that, but it's close enough).

./something # this tries to run the file `something` in the current directory as
# an executable. It doesn't need to be a shell script -- it can be
# any kind of executable, and if it has a shebang line, that will be
# honored to determine the interpreter or shell to use.

./ something # <- this is simply invalid.

That said, you can record exactly what commands your script is running by starting it like so:

ksh -x ./something

This will display the commands your script runs. If the fault is caused by the script starting the JVM incorrectly, you can thus determine how the expected and actual invocations differ.

./ Dot Slash not working to execute Shell Scripts

you can run command chmod 755 script.sh

and then run the script with ./script.sh

How to stripoff the string after space, slash (/), greater than ( ),dot(.) in shell

In shell you can do string manipulation:

s='a15-ap-99995>wma.ibm.com'
echo "${s/[,\/. >]*/}"
a15-ap-99995>wma

s='a15-ap-5035.wma.ibm.com'
echo "${s/[,\/. >]*/}"
a15-ap-5035

Using `perl:

perl -pe 's~[,/>. ].*~~' <<< "$s"

What is double dot(..) and single dot(.) in Linux?

They are special name-inode maps which do count as hard-links (they do increase the link-count) though they aren't really hard-links, since, as you said, directories can't have hard-links. Read more here: Hard links and Unix file system nodes (inodes)



Related Topics



Leave a reply



Submit