Any path that starts with /
is an absolute path, not relative.
If all paths were always relative to the current directory, how would you cd /etc
in the first place? You'd have to cd ../../../../../etc
and hope that was enough levels of ..
, or just keep doing cd ..
until you got to the root directory.
Or you'd need some other syntax to express absolute paths. But Unix decided on /
meaning absolute, anything else being relative to the process's current working directory. So mv MyFile.txt openvpn
would work.
And no, it wouldn't work well to infer absolute vs. relative from files existing or not. We wouldn't want mkdir
system calls to treat paths differently from chdir
or rename
system calls, and making the mv
program do it just leaves room for inconsistency between mv
and some other program that takes an output filename.
mv
is already special because when the rename()
destination is a directory, it appends the source filename to that destination directory and tries again. But notice that one simple implementation strategy relies of the first rename()
system call failing with EEXIST
or EISDIR
. So we have to know whether a path is relative or absolute before checking the filesystem.
(Early Unix ran on slow computers, where extra checks if a directory existed could mean extra I/O if it wasn't cached, or more pressure on directory caching. But I think sanity / correctness arguments are sufficient to explain why your first guess wasn't a plausible way for the system to work, without resorting to historical efficiency arguments.)