Understanding the PS1 Shell Prompt (Instead of Just Memorizing It)

One thing I appreciate about the Red Hat training material is that even a small exercise usually teaches several Linux concepts at once.

However, if you’re self-studying for the RHCSA exam, it’s easy to fall into the habit of simply copying commands from the workbook without understanding why you’re doing them.

In this article, we’ll take one of the simplest RH134 Bash exercises and break it down into what it’s actually teaching.

The Exercise

Task

Modify the PS1 shell variable to include the current time by editing your ~/.bashrc file.

Set the prompt to:

PS1='[\u@\h \t \w]$ '

After making the change, reload the configuration.

Before You Begin

The official RH134 workbook performs this exercise on a preconfigured lab environment using machines named workstation and servera.

If you’re using your own Linux VM (RHEL, Rocky Linux, AlmaLinux, Fedora, Ubuntu, etc.), you can simply perform the exercise on your current machine.

Question 1

Modify the shell prompt by editing the ~/.bashrc file so it displays the current time.

What is this question actually asking?

The question isn’t really asking you to make your terminal look nicer.

It’s asking you to customize the behavior of your Bash shell using a configuration file.

Why is the question designed like this?

Red Hat wants you to understand that many Linux settings are controlled through configuration files.

Rather than hardcoding behavior into the shell, Bash reads a configuration file whenever a new shell starts.

Learning this workflow prepares you for editing many other Linux configuration files later, such as:

• SSH configuration
• Web server configuration
• System services
• User environments

What skill are you learning?

By completing this step, you learn:

• where user-specific shell configuration is stored
• how to customize your shell
• how Bash variables affect shell behavior
• how configuration files are used throughout Linux

Answer

Open your Bash configuration file.

nano ~/.bashrc

Add the following line near the end of the file.

PS1='[\u@\h \t \w]$ '

Save the file.

Understanding the Prompt

Each special sequence has a meaning.

CodeMeaning\uCurrent username\hHostname\tCurrent time\wCurrent working directory

So this:

PS1='[\u@\h \t \w]$ '

might display:

[ravindu@rhel9 14:45:05 ~]$

Notice the space after $.

That trailing space simply makes typing commands more readable.

Instead of:

[ravindu@rhel9]$ls

you get:

[ravindu@rhel9]$ ls

Question 2

Reload the updated ~/.bashrc file.

What is this question actually asking?

Tell your current shell to read the configuration file again.

Why is the question designed like this?

Editing a configuration file doesn’t automatically change the running shell.

Bash only reads .bashrc when a shell starts.

Without reloading it, nothing appears to happen.

What skill are you learning?

You’re learning how to apply configuration changes without logging out.

This is a workflow you’ll use constantly as a Linux administrator.

Answer

Run:

source ~/.bashrc

or

. ~/.bashrc

Both commands do exactly the same thing.

What does source actually do?

Think of it like this.

When you open a terminal:

Open Terminal
      ↓
Read ~/.bashrc
      ↓
Load variables into memory

If you later edit .bashrc, the shell doesn't automatically notice.

Running:

source ~/.bashrc

simply tells Bash:

“Read this file again and execute everything inside it.”

Your prompt immediately updates without needing to log out.

How the Two Questions Connect

These two questions form a workflow that you’ll see repeatedly throughout Linux administration.

Edit a configuration file
          ↓
Save the file
          ↓
Reload the configuration
          ↓
Verify the result

Today it’s the Bash shell.

Tomorrow it might be SSH.

Next week it might be a web server, firewall, or network configuration.

The workflow remains exactly the same.

What You Learned

Although this exercise looks small, it introduces several important Linux concepts.

• User-specific shell configuration is stored in ~/.bashrc.
• The Bash prompt is controlled by the PS1 shell variable.
• Shell variables influence Bash’s behavior.
• Editing a configuration file doesn’t automatically apply changes.
• The source command reloads a configuration file into the current shell.
• Linux administration often follows the pattern of Edit → Reload → Verify.

Question 3

Define a shell variable named file that contains the value examplefile.

file=examplefile

What is this question actually asking?

Create a shell variable and store a piece of text inside it.

At first glance, this seems unnecessary. Why not just type examplefile every time?

That’s exactly what Red Hat wants you to think about.

Why is the question designed like this?

Linux administrators often repeat the same values throughout a script or terminal session.

Instead of repeatedly typing:

• a filename
• a directory
• an IP address
• a username
• a service name

you can store it once and reuse it.

For example, instead of:

ls -l /var/log/httpd/access.log
cp /var/log/httpd/access.log backup.log
rm /var/log/httpd/access.log

you could write:

log=/var/log/httpd/access.log

ls -l $log
cp $log backup.log
rm $log

Now if the filename changes, you only update it in one place.

This is one of the biggest reasons variables exist.

What skill are you learning?

You’re learning how to:

• create shell variables
• avoid repeating values
• write commands that are easier to maintain
• prepare for Bash scripting

Answer

file=examplefile

Notice there are no spaces around the equals sign.

Correct:

file=examplefile

Incorrect:

file = examplefile

Bash interprets the second version as three separate words instead of a variable assignment.

Question 4

Retrieve the value stored in the variable.

echo $file

What is this question actually asking?

Display the contents of the variable.

Not the variable name itself, but the value stored inside it.

Why is the question designed like this?

Creating variables is only half the story.

You also need to know how to retrieve their values.

The $ symbol tells Bash:

“Replace this variable with whatever value it currently contains.”

What skill are you learning?

Variable expansion.

This is one of the most important Bash concepts you’ll encounter.

Without variable expansion, shell scripting wouldn’t be very useful.

Answer

echo $file

Output:

examplefile

Think of Bash doing this internally:

echo $file

↓

echo examplefile

The shell performs the substitution before running the command.

Question 5

Use the variable with the ls -l command.

ls -l $file

What is this question actually asking?

Use a variable anywhere Bash expects a filename.

Why is the question designed like this?

This demonstrates that variables aren’t just for displaying values.

They can replace command arguments entirely.

Bash expands the variable before executing the command.

Internally, it becomes:

ls -l examplefile

What skill are you learning?

How variables integrate into everyday Linux commands.

You’ll use this constantly in shell scripts.

Answer

ls -l $file

Example output:

-rw-r--r-- 1 student student 0 Jan 23 14:59 examplefile

Question 6

Delete the file using the variable.

rm $file

What is this question actually asking?

Use the variable again — but this time with another command.

Why is the question designed like this?

Red Hat wants you to realise that variables are reusable.

You define them once and use them wherever needed.

Instead of:

rm examplefile

you write:

rm $file

The command is more flexible and easier to maintain.

What skill are you learning?

Reusing variables across multiple commands.

This is the foundation of automation.

Answer

rm $file

Question 7

Verify that the file has been deleted.

ls -l $file

What is this question actually asking?

Confirm that your previous command actually worked.

Why is the question designed like this?

One of the habits every Linux administrator develops is verification.

Never assume.

Always confirm.

Whether you’re:

• deleting files
• restarting services
• changing permissions
• creating users

verify the result.

What skill are you learning?

Verification.

This habit becomes incredibly important when managing production servers.

Answer

ls -l $file

Output:

ls: cannot access 'examplefile': No such file or directory

That error message is actually good news.

It confirms the file no longer exists.

Question 8

Export the EDITOR variable.

export EDITOR=vim

What is this question actually asking?

Create an environment variable instead of a regular shell variable.

Why is the question designed like this?

This is where the exercise introduces one of Bash’s most important distinctions.

Not all variables are the same.

There are two main types:

Shell variables

Only exist inside the current shell.

Environment variables

Are inherited by programs started from that shell.

Many Linux programs look for specific environment variables to determine how they should behave.

One of those variables is EDITOR.

Some applications ask:

“Which text editor should I launch?”

If EDITOR=vim, they'll open Vim automatically.

What skill are you learning?

The difference between:

• shell variables
• environment variables

This distinction appears throughout Linux administration.

Answer

export EDITOR=vim

You can think of export as saying:

“Make this variable available to any child processes started from this shell.”

Question 9

Verify the value of the environment variable.

echo $EDITOR

What is this question actually asking?

Confirm that the environment variable exists and contains the expected value.

Why is the question designed like this?

Just like earlier, Red Hat reinforces another important habit:

Always verify your changes.

Configuration without verification is just a guess.

What skill are you learning?

Checking environment variables.

You’ll use this frequently with variables like:

• PATH
• HOME
• USER
• SHELL
• EDITOR
• LANG

Answer

echo $EDITOR

Output:

vim

How These Questions Connect

Notice how each question builds naturally on the previous one.

Customize the shell
        ↓
Reload the configuration
        ↓
Create a shell variable
        ↓
Read the variable
        ↓
Use the variable with commands
        ↓
Reuse the variable
        ↓
Verify the result
        ↓
Introduce environment variables
        ↓
Verify again

Rather than teaching isolated commands, the workbook gradually introduces the concepts that make Bash powerful.

What You Learned From This Exercise

Although this exercise only uses a handful of commands, it introduces several foundational Bash concepts.

You learned how to:

• Customize your shell prompt with the PS1 variable.
• Reload shell configuration using source.
• Create shell variables.
• Retrieve variable values with echo.
• Use variables as command arguments.
• Reuse variables to make commands easier to maintain.
• Verify the results of your commands instead of assuming they worked.
• Understand the difference between shell variables and environment variables.
• Export environment variables so child processes can access them.

Together, these concepts form the foundation of Bash scripting.

The individual commands may seem simple, but they teach habits you’ll use every day as a Linux administrator: configure, reuse, automate, and verify.

Final Thoughts

One thing I’ve started doing while studying RHCSA is asking a simple question after every exercise:

“What skill is Red Hat actually trying to teach me?”

The answer is often much bigger than the commands themselves.

In this case, the exercise isn’t really about changing your prompt.

It’s about understanding one of the most important ideas in Linux administration:

Configuration is stored in text files, and administrators control system behavior by editing those files.

Once you recognize that pattern, many RHCSA exercises start making much more sense.