As title says, is there any difference for *NIX filesystems? e.g ls file
and ls ./file
2 Answers
I'm not crazy about the explanation by SmallLoanOf1M. It is technically correct but answers in a way that doesn't match the usage example in the question.
So by way of example, here is one important difference between the two from the question: "file" and "./file"
What if the file is named with a character that is parsed by the shell? Especially regarding characters interpreted by the command one is running.
Specifically, the "dash" character: "-". But other characters are meaningful to the shell.
Example. My file was named "-dingle"
Try to list the file:
ls -dingle
# ls -dingle
ls: invalid option -- 'e'
Even worse, what if the file was named "-rf rmbomb *
"? Now try removing it
rm "-rf rmbomb *"
I'm not even gonna try to run that example, but hopefully you get the idea.
So how do you list a file staring with dash? Use ./
in front.
# ls ./-dingle
./-dingle
Ditto for rm
-
That is a valid way to process some files with odd names, and my answer didn't consider files like that. One could also use a literal instead in all of the examples above, in the form of a backslash preceding odd characters, including the spaces specified above. An example of that would be so:
ls \-dingle
orls \-rf\ rmbomb\ \*
. This can be a good way to ensure that any given set of commands are at least consistent, as specifying./
before a name won't escape characters after the./
.– SpoolerOct 21, 2016 at 21:35 -
2It happens that, since escapes are escaped by the shell, not the command, and params are parsed by the command, escaping or quoting the - does nothing useful. Oct 21, 2016 at 22:08
-
2You make it sound like
rm "-rf rmbomb *"
would actually do something bad, instead of just makingrm
print an error. It's only dangerous if you forget to quote the filename, so word-splitting happens. (esp. in a shell script where you runrm $file
instead ofrm "$file"
. But in that case, the*
won't expand, because glob expansion doesn't happen on the contents of variable expansion. If you want that, you'd need aneval
.) Anyway, if your script word-splits filenames before passing to rm, I'd make a file calledspace -rf .
or something, sorm ./$i
doesn't help. Oct 22, 2016 at 3:20 -
1BTW, the actual error message is
rm: invalid option -- ' '
, from when it tries to interpret the space after-rf
as a single-character switch, because it's part of the same argument. (And yes, I ran this inside an empty directory just in case I had overlooked something and it was actually dangerous :P) Oct 22, 2016 at 3:21 -
2@PeterCordes: wordsplitting and globbing DOES occur on the results of unquoted variable expansion and command substitution, unless suppressed by
IFS=''
and-f
respectively. A rarer example is thatawk
treats an operand (other than a first operand that is the script) having formfoo=bar
as an assignment to execute but./foo=bar
as a file to read. Oct 22, 2016 at 6:26
Yes.
By issuing file
on the command line, BASH will search your $PATH environment variable for a file of that name. Unless the file resides in a directory within your $PATH variable, it won't be found.
.
means the current directory. ./
means within the current directory, in relative terms. It is the equivalent of saying something like /home/sheogorath/shivering/isles.img
when invoking ./isles.img
while working in the /home/sheogorath/shivering/
directory.
As such, it's commonly used to execute files within your working directory "in place".
EDIT:
In your example, ls
is being called upon by the shell and found by using the path variable. Its argument will be processed in your working directory, whatever that may be. Since this is the default for ls
, you won't see any difference between specifying file
and explicitly specifying ./file
as they both point to your current directory.
Not all commands will accept file paths in the working directory, and some expect to have you state files in a directory that they themselves pre-define via configuration. Among commands that accept files as arguments, these commands are less common
-
1That is bash, but I was wondering about path resolution in general Oct 21, 2016 at 20:04
-
1This is the way any shell I've ever heard of works. BASH is merely the most commonly used.– SpoolerOct 21, 2016 at 20:04
-
4$PATH is only relevant for commands and has nothing to with file name arguments that follow a command such as
ls
mentioned in the original question. That is more the difference between refferencing a relative path ( relative to the current working directory) I.e.../../dir/filename
and an absolute path/path/to/dir/filename
– HBruijnOct 21, 2016 at 20:21 -
1
-
1If they're arguments to a command that attempts to find files in the working directory by default, they will be the same. Thus, for
ls
they will always be the same path, one specified more explicitly than the other. Not all commands behave this way when processing arguments, but most do.– SpoolerOct 21, 2016 at 20:38