Does using ./ in paths make sense with common Unix tools?

Question

Throughout the years I've been using ./ in front of absolute paths more and more. For example:

mv ./file /target/
rm ./something/else

# compared to
mv file /target/
rm something/else

I've seen it in more places around the web, which is probably why I adapted to using it. I can't seem to understand why this is done though, and have been wondering for a while. Maybe it's a bad habit originating from calling local binaries directly: ./a.out

Is the ./ obsolete in the shell example above? Is there any reason to use ./ in some cases? Does using it possibly make paths more explicit?

Answer 1

It's not a bad habit to specify explicitly that something is located in the current directory, especially when that something is a script or program (the alternative in that case would be to have . in your $PATH which is generally considered to be a security risk).

There are situations where you will have ./ at the start of a pathname no matter if you want it or not. For example, the pathnames found by find when searching from . downwards will always be prefixed by ./.

In other situations, a filename may interfere with the options of a utility, as when trying to remove a file called -f with

rm -f

Using

rm ./-f

would solve that (the ./-f would not be taken as an option to rm), as would

rm -- -f

do (the -- signals the end of any command line options).

Also note that shell globs, such as * may expand to files with an initial dash. It is therefore safer to e.g. loop over ./* than over * (unless you use -- to delimit the unknown filename from the options given to utilities).

It is therefore a good idea to use ./ in pathnames, particularly if the pathname is stored in a variable and comes from some source external to the script.