Learn › Linux Foundations › Bash Shell Environment
.bashrc - a hands-on Linux lab on a real virtual machine.
The ~/.bashrc file is your personal startup script: bash runs it for every new interactive terminal, so whatever you put there (aliases, exports, PATH additions) comes back automatically. Prove a hand-set alias is temporary, append a setting to a file, and apply it to your running shell with source. A change to ~/.bashrc is invisible to the current shell until a new terminal or source ~/.bashrc reloads it.
You set up the perfect shortcut. You typed alias ll='ls -alF' so that ll would give you a full, detailed listing without the long typing. It worked all afternoon. Then you closed the terminal, opened a fresh one the next morning, typed ll, and got command not found. Your shortcut was gone.
You did nothing wrong. You just met a basic fact about the shell: everything you set by hand lives only in that one terminal, and dies when you close it. If you want a shortcut, a setting, or a PATH entry to come back every single time, it has to be written down somewhere the shell reads on startup. That somewhere is a file called .bashrc, and this lesson is about how it works.
The black boxes in this lesson are a practice terminal: a safe sandbox that checks the one command each step teaches, so nothing you type can break anything. A real ~/.bashrc is different on every machine, so where you see one printed here it is one representative example, marked as such. The other outputs are built from things you set yourself, so they are the same everywhere.
.bashrc is a plain text file in your home folder, written as ~/.bashrc. The ~ is shorthand for your home directory, and the leading dot means it is a hidden file, so a plain ls will not show it. Inside, it is just a list of shell commands, one per line.
Here is the key idea. Every time you open a new terminal, bash reads ~/.bashrc from top to bottom and runs every line in it, before it ever shows you a prompt. So it is your personal startup script: a to-do list the shell runs for you at the start of each session. Whatever you put in there, an alias, an exported variable, a PATH addition, happens automatically in every new terminal. That is the fix for the vanished shortcut. You do not set it by hand each morning. You write it in ~/.bashrc once, and the shell sets it for you forever.
The rc in .bashrc stands for run commands, a naming habit that goes back to the earliest Unix in the 1970s. You will see the same rc ending on many config files, like ~/.vimrc for the vim editor. Wherever you see a dot-something-rc file, read it as "the commands this program runs at startup."
Before you change the file, see what one looks like. cat prints a file to the screen, and cat ~/.bashrc prints your startup script. A typical one has a mix of things: some alias lines, an export or two, maybe a line that adds a folder to PATH.
cat ~/.bashrc
prompt: student@linuxcamp:~$ answer: cat ~/.bashrc output:
alias ll='ls -alF' alias la='ls -A' export EDITOR=vim export PATH="$HOME/bin:$PATH" hint: Use cat, a space, then the path to the file: cat ~/.bashrc
That exact file belongs to the machine this was captured on. On YOUR machine ~/.bashrc will read differently: a different set of aliases, different exports, and usually many more lines, since most systems ship a long default .bashrc full of comments. What stays the same everywhere is the ROLE of the file, a list of shell commands run at every new terminal, not these specific lines. So this is the one output in the lesson you should read for shape, not memorise.
Feel the problem for yourself before you fix it. Set an alias by hand, right in the shell, and check that it took. alias NAME='command' creates the shortcut, and alias NAME on its own asks bash to print back the definition it is holding.
Before you run it, commit to an answer: after you set it, what does alias ll print back?
alias ll='ls -alF'; alias ll
prompt: student@linuxcamp:~$ answer: alias ll='ls -alF'; alias ll output: alias ll='ls -alF' hint: Define the alias, a semicolon, then ask for it by name: alias ll='ls -alF'; alias ll
Bash echoed the definition straight back: alias ll='ls -alF'. The shortcut is live in THIS terminal right now. But it exists only here, only in memory, only until you close the window. Nothing was written to any file. That is the whole trap from the cold open: a hand-set alias is real but temporary. To make it survive, it has to go into ~/.bashrc, which is what you do next.
To make the shortcut come back in every terminal, you write the alias line into ~/.bashrc. The safest way to add a line to the end of a file, without touching what is already there, is >>, the append operator you met in the redirection lessons. echo 'text' >> file writes text as a new last line.
You will practice the exact move on a throwaway file called demo.rc, so nothing real is at stake, then read it back to confirm the line landed. Before you run it, commit to an answer: after you append it, what does cat demo.rc show?
echo "alias ll='ls -alF'" >> demo.rc; cat demo.rc
prompt: student@linuxcamp:~$ answer: echo "alias ll='ls -alF'" >> demo.rc; cat demo.rc output: alias ll='ls -alF' hint: Echo the line, append with >>, then cat the file: echo "alias ll='ls -alF'" >> demo.rc; cat demo.rc
The file now holds your alias line: alias ll='ls -alF'. The >> appended it to demo.rc without disturbing anything else, and cat read it straight back. In real life you would append that same line to ~/.bashrc instead of demo.rc, and from then on every new terminal would read it and set ll for you. You just performed the exact edit that makes a shortcut permanent, on a safe practice file.
Stop and see what you can now do. You proved a hand-set alias is temporary, and you learned the one move that makes it permanent: write the line into ~/.bashrc. That single skill is how engineers carry their setup with them. Every alias they lean on, every export that tunes a tool, every folder they add to PATH, it all lives in that one startup file. And it all comes back automatically, because the shell reads the file at the start of every session. You now understand the file that turns a throwaway shell into your shell.
Here is the part that trips up almost everyone. You just added a line to ~/.bashrc. You might expect the alias to work right away in the terminal you are sitting in. It does not.
The reason is exactly what you learned: bash reads ~/.bashrc when a terminal STARTS. Your current terminal already started, minutes or hours ago, so it read the old version of the file and has not looked again. Editing the file changes what FUTURE terminals will read; it does nothing to the one already open. Your edit is real, saved, and on disk, but the running shell is unaware of it.
So after editing ~/.bashrc you have two honest choices. Open a brand-new terminal, which reads the fresh file from the top. Or tell the shell you are in to read the file again, right now, without restarting. The second choice is a command called source.
source ~/.bashrc tells your current shell to read and run the file this instant, in the shell you are already in, so every change takes effect immediately with no new terminal. It is the standard way to apply a .bashrc edit right away.
You will feel the reload on the same safe demo.rc. It holds the alias line you appended. source demo.rc runs that line in your current shell, which defines the alias here and now. Then alias ll proves the shortcut is live. Before you run it, commit to an answer: after sourcing, does alias ll print the definition?
source demo.rc; alias ll
prompt: student@linuxcamp:~$ answer: source demo.rc; alias ll output: alias ll='ls -alF' hint: Source the file to run its lines now, then ask for the alias: source demo.rc; alias ll
Bash printed alias ll='ls -alF', so the shortcut is live in this very shell without opening a new terminal. source demo.rc read the file and ran the alias line inside your current shell, exactly the way bash runs ~/.bashrc at startup, just triggered by you on demand. That is the everyday rhythm: edit ~/.bashrc, then source ~/.bashrc to feel the change at once. There is even a shorter spelling, a single dot, so . ~/.bashrc does the same thing as source ~/.bashrc, but the word source is clearer while you are learning.
One honest wrinkle, because it explains a confusion you will eventually hit. Bash reads ~/.bashrc for interactive non-login shells: the ordinary case of opening a new terminal window or tab on a desktop, where you sit and type commands. That is almost always the shell you are in.
A login shell, the kind you get when you connect to a remote machine over SSH or log in at a text console, reads a different file first, ~/.bash_profile, and does not read ~/.bashrc on its own. To avoid keeping two separate setups, ~/.bash_profile almost always contains a line that sources ~/.bashrc, so your aliases and settings still load. Both of those files, and exactly when each one runs, are lessons of their own coming next in this module. For now, hold one fact: ~/.bashrc is the file for your everyday terminal.
Two things bite people often enough to name.
The first is a typo in ~/.bashrc itself. Because bash runs the whole file at every new terminal, a broken line does not sit quietly. It shouts on startup. Put a stray line like exprt PATH=/usr/bin in the file, open a new terminal, and you are greeted with:
bash: exprt: command not found
every single time you open a shell, because bash tries to run that bad line at every startup. What to check first: open ~/.bashrc, find the line the error names, and fix or delete it. This is why careful engineers keep a backup before editing, with cp ~/.bashrc ~/.bashrc.bak, so a bad edit is one copy away from undone.
The second is the one from earlier, worth repeating because it is the single most common .bashrc confusion: you edit the file, nothing changes, and you think the edit failed. It did not. The running shell has not re-read the file. Either open a new terminal or run source ~/.bashrc. A saved edit and an applied edit are two different things.
Keep ~/.bashrc fast. Every line in it runs at the start of every terminal, so a slow command in there, something that reaches out to the network or scans a huge folder, makes every new terminal slow to open. Startup files are for quick settings: aliases, exports, PATH tweaks. Leave the heavy work for when you actually ask for it.
Scaffolding off. No command is printed this time. You have every piece you need.
You want a permanent shortcut. Append the line alias gs='git status' to your demo.rc file so it is saved, then apply it to your current shell right away without opening a new terminal, and finally have bash print the alias definition back so you can see it is live. Build the whole line yourself.
prompt: student@linuxcamp:~$ answer: echo "alias gs='git status'" >> demo.rc; source demo.rc; alias gs output: alias gs='git status' hint: Three moves joined by semicolons: echo the alias line with >> demo.rc, then source demo.rc, then alias gs.
Bash printed alias gs='git status', which means all three moves landed. The >> saved the alias line into the file, source demo.rc read that file into your current shell so the alias came alive without a new terminal, and alias gs proved it. Swap demo.rc for ~/.bashrc and that is the exact real-world sequence for adding a permanent shortcut and using it the same minute. You built it from memory, which is the same recall the real machine will ask of you.
You earned this cheat sheet. Every row is a move you just ran or met:
The one idea to carry out: ~/.bashrc is the file that makes your shell settings permanent. Write a setting into it once and every new terminal runs it for you. Edit it, then source ~/.bashrc to apply the change without restarting.
The practice terminal has shown you the whole story of ~/.bashrc. You saw what a startup script holds, proved a hand-set alias is temporary, appended a setting to a file, and applied it to your running shell with source. You learned that editing the file does nothing to the shell you are in until you reload it, and you met the error a bad line prints at every startup. Every one of those you typed yourself.
The Bash Environment module ends with one real Linux machine, the Bash Environment capstone mission, and that is where you edit a real ~/.bashrc. A VM boots just for you, with its own home folder and its own startup file you can add aliases and exports to, source, and watch take effect. It hands you objectives that use exactly what you practiced across this module: variables, env, export, PATH, and the startup file that makes them all permanent. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.
Finish the other Bash Environment lessons, then go make a shortcut permanent on a real machine for yourself.
Practice .bashrc in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.