Since the preceding dot is really part of the filename, it is processed by many apps as per any other file when it comes to regular expressions. The only complication is that . is also shorthand for $PWD. Considering files starting with . as "hidden" is a shell-ism rather than a filesystem feature -- the filesystem itself doesn't really treat files or directories starting with a period as "hidden."
No it isn't - the "." is interpreted by the kernel to mean "current working directory".
It is not handled directly by any application, or even the open system call - other
than that done inside the kernel.
The environment variable PWD doesn't even have to exist - This is an extension that
some shells have added as a convenience when writing shell scripts. It is directly
except that it doesn't require a new process (the `pwd`) to implement.
You can see this if you do:
[jesse@panther ~]$ echo $PWD
[jesse@panther ~]$ PWD=xyz
[jesse@panther xyz]$ echo $PWD
The current working directory is part of the process context - and is used to allow
applications to shorten file names. If a file is opened - as in open("name"...) - then
the system will concatenate the current working directory with "/" and "name" to
generate the full path to the file. If a file is opened - as in open("./name"...) - then
it means "look in the current directory", and the kernel opens the directory "." to
search for the name.
This works exactly the same way that open("../xyz"...) means "look in the current
directory for the directory named ".." and search for the file named "xyz".
I believe (haven't looked recently) this is being interpreted by the VFS (virtual file
system) layer in the "namei" (name to inode translation) function.
As a side note: the file "xyz/../abc" is handled the same way. The system opens
the directory xyz in the current directory, then opens the file .. (which is the parent
directory, or the current directory) to locate the file "abc". It just takes more
work. But handling of the ".." is not any different.