Hidden Files and the Meaning of the Dot

Part I · Module 2 · Chapter 2.6 · Hidden Files and the Meaning of the Dot

1. The Missing Entries

Start in a home directory and list it:

$ cd ~

$ pwd
/home/engineer

$ ls
project

One entry. On an account that has been used for months, that is implausible — and it is not what is actually there.

Now the same directory, with one more option:

$ ls -a
.  ..  .bash_history  .bashrc  .config  .profile  .ssh  project

Eight entries instead of one. Nothing was created between the two commands, and nothing moved. The second command simply asked for everything.

2. The Rule Is One Sentence

A name that begins with a dot is left out of ls output unless you ask for it.

That is the entire convention. There is no flag stored on the file, no special attribute, no setting. The rule is about the name: first character a dot, left out.

-a is for all:

$ ls -a
.  ..  .bashrc  .config  project

A close relative is -A, which shows everything hidden except . and ..:

$ ls -A
.bashrc  .config  project

Chapter 1.5's note applies — these are two different short options, and the difference between lower and upper case matters, as it does for most options.

In speech, files named this way are called dotfiles.

3. Who Is Doing the Hiding

This is the part worth getting exactly right, because the natural assumption is wrong.

The filesystem is not hiding anything. The kernel is not hiding anything. ls is.

ls is an external program, as Chapter 1.7 established — a file on disk with its own author and its own behaviour. Somebody decided, long ago, that it would skip names starting with a dot unless asked. Everything else on the machine treats such a file as entirely ordinary.

You can demonstrate that in one line. cat prints a file's contents, and Chapter 4.1 teaches it properly:

$ cat .bashrc
# ~/.bashrc: executed by bash for non-login shells.

No option was needed, no permission was granted, nothing was unhidden. cat was given a path and it read the file, because as far as cat is concerned there is nothing unusual about it.

The same is true of every program you will ever use. A text editor opens a dotfile normally. A compiler reads one normally.

4. The Loop This Module Left Open

Look again at the first two entries of ls -a, the shorthands from Chapter 2.3:

$ ls -a
.  ..  .bashrc  .config  project

There they are. . and .. — the shorthands from Chapter 2.3 — listed as entries of this directory, because that is exactly what they are.

They were hidden by the same rule as everything else: both names begin with a dot. Nothing special was ever happening. Chapter 2.3 said the filesystem genuinely stores them, Chapter 2.4 showed listings without them, and the reconciliation is simply that ls was not mentioning any dotted name.

This also explains the link counts from Chapter 2.5. A directory's count starts at 2 because two names point at it — its own name in the parent, and the . entry inside it. You can now see the second one.

5. Why the Convention Exists

Not for secrecy. For quiet.

A home directory accumulates configuration — one file or directory per program that wants to remember something about you. A typical account has dozens. If ls showed them all, the handful of files you are actually working on would be buried every time you looked.

So the convention splits a directory in two: the things you work on, and the things that configure your environment. One ls gives you the first group; ls -a gives you both.

Here is what is typically in a home directory:

Two of those connect directly to things you have already seen. .bash_history is literally where Chapter 1.8's history goes when a session ends. .bashrc is where the prompt that Chapter 1.4 told you was "configurable text" gets configured.

What is inside those files, and exactly which one Bash reads when, is Module 10's subject. It needs variables first, which is Module 8. Knowing the files exist and what they are for is the right amount for now — and it is the answer to "where do my settings actually live", which is a question most people carry unanswered for a long time.

6. Not a Security Feature

This section exists because the wrong model here is actively harmful.

A leading dot provides no protection whatsoever. It is not permission, not encryption, not access control. Anyone who can read the directory can see the name — they need only pass one option — and anyone with permission to read the file can read it whether it starts with a dot or not.

Renaming secrets.txt to .secrets.txt changes exactly one thing: whether ls mentions it by default. It changes nothing about who may open it.

What actually controls access is ownership and the permission string from Chapter 2.5 — the rw-r--r-- field — and that is Module 5's entire subject. Notice, for instance, that ls -la on a home directory usually shows .ssh with far stricter permissions than its neighbours. That strictness is doing the protecting. The dot is doing nothing.

7. Listing Just the Dotfiles

A reasonable thing to want: see the dotfiles and nothing else.

$ ls -d .*
.  ..  .bashrc  .config  .profile  .ssh

Two things are happening in that command, and they belong to two different programs.

The .* is the shell's doing. Chapter 1.2 demonstrated this with echo *: before ls runs, Bash replaces the pattern with the matching names. ls never sees a * at all — it receives a list of already-expanded names. The rules for these patterns are Module 3's subject and the complete expansion story is Module 9's; nothing more is needed here.

The -d is ls's doing, and it is Chapter 2.5's option: describe each name given, rather than looking inside it. Without -d, ls would be handed .config and .ssh — both directories — and would list their contents, which is not what was asked.

Notice the output includes . and .., because both of those names match a pattern starting with a dot. That is a known annoyance rather than a mistake. It also quietly matters: a pattern like .* used with a command that changes things will include the current directory and its parent, which is almost never what anyone intends. Module 3 covers the safer forms; the thing to carry now is that .* matches more than you expect.

8. Where This Bites

Three realistic situations.

"My file disappeared." A file renamed to start with a dot — easily done by a mistyped command — vanishes from ls while remaining perfectly intact. ls -a finds it immediately. Nothing was lost.

"I copied the directory but my settings are gone." Copying tools follow the same convention in places, so a copy made with a pattern like * silently leaves every dotfile behind. The files were never selected, because * does not match names beginning with a dot. This is Module 3's territory and one of the practical reasons that module spends time on it — the symptom shows up much later, as a program that has mysteriously forgotten its settings.

"Deleting the obvious thing deleted more than I meant." Related to §7: patterns involving a leading dot can include . and .., and a destructive command given those is a famously bad afternoon. Module 20 builds the guards that make this impossible to do accidentally. For now, simply know that .* is not as narrow as it looks.

9. Engineering Note

The convention shows up in engineering work in one form you will meet early.

Project directories commonly contain dotfiles that configure the tools used in that project rather than the user — a version-control directory, editor settings, tool configuration. They are deliberately kept out of the way because they are not part of the work, and ls quietly cooperates.

The practical consequence is small and specific: when you are inspecting an unfamiliar project directory and trying to understand how it is set up, ls -a often shows the half of the answer that ls was leaving out. Part II returns to reading unfamiliar repositories properly, once you have the search tools for it.

10. Practice

Assume a home directory containing exactly: project, .bashrc, .config, .ssh, notes.txt.

Question 1. How many entries does ls show, and how many does ls -a show? Account for the difference precisely.

Question 2. Which program decides not to display dotfiles — the kernel, the filesystem, or ls? Give one command that demonstrates your answer.

Question 3. You rename notes.txt to .notes.txt. Who can now read it that could not before, and who can no longer read it?

Question 4. Chapter 2.5 said a directory's link count starts at 2. Using this chapter, name the two entries being counted.

Question 5. ls -d .* lists . and .. among its results. Explain which component produced that list, and why those two names are included.

Question 6. A colleague copied their home directory to a new machine and reports that their shell prompt and aliases are gone, though their documents came across. What is the most likely explanation?

Question 7. Why is .config better described as "not mentioned by default" than as "hidden"?

11. Remember

• A name beginning with a dot is left out of ls output unless you ask for it with -a (everything) or -A (everything except . and ..).
• ls does the hiding — not the kernel, not the filesystem. Every other program treats a dotfile as entirely ordinary, and cat .bashrc proves it.
• . and .. are dotfiles too. That is why this module's earlier listings did not show them, and why a directory's link count starts at 2.
• The convention exists for quiet, not secrecy — it keeps dozens of configuration files out of the way of the few you are working on.
• It is not a security feature. Permissions and ownership control access; the dot controls nothing. Module 5 owns the real mechanism.
• Your settings live in dotfiles in your home directory — .bashrc, .profile, .ssh, .config. What is in them is Module 10.
• Patterns beginning with a dot match more than you expect, including . and ...
• When something seems missing, run ls -a first.

That completes Module 2. You now have a picture of the whole tree and a single root; a notation for pointing anywhere in it, absolute or relative; the shorthands that make real paths short, and the knowledge of which of them is a directory and which is the shell rewriting your line; three commands for moving and confirming; and the ability to read every field a listing gives you — including the entries it does not volunteer. Module 3 starts changing that tree: creating directories and files, copying, moving, and the one command on this system that has no undo.