Edit Files on a Linux Server

Use Vim and Nano to create and edit bash scripts like a cloud engineer.

Introduction

30 Second Summary

Every cloud job eventually puts you on a remote Linux server with nothing but a terminal. There is no familiar code editor, no mouse, and no menus.

In this project, you will use Nano and Vim to create bash scripts, edit configuration files, and build a server health check tool inside your WSL Ubuntu terminal. You will walk away with the confidence to open and edit any file on any server.

What You'll Build

You will run a health check script that fills your terminal with system diagnostics and saves them to a log file, built using the same tools you would use on a real EC2 instance.

By the end of this project, you'll have:

  • A server info script you can run to see your hostname, OS, disk usage, and memory printed to the terminal.
  • The muscle memory to open any long config file in Vim, jump to the exact line you need, and make targeted edits using Normal mode commands.
  • A health check script that logs your system's full diagnostics to a file, built entirely in Vim combining Insert mode for writing and Normal mode for editing.
  • Secret Mission: Customize your shell environment by editing .bashrc with Vim to add aliases and a custom prompt.

Are there any prerequisites?

This project requires WSL 2 with Ubuntu installed on your Windows machine. If you need help setting this up, check out Microsoft's official WSL documentation.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Every cloud engineer eventually SSHs into a Linux server and needs to edit a file. This project gives you the muscle memory to handle that moment with confidence.

Set Up Your Terminal Editing Tools

Before you can edit files on a Linux server, you need the right tools installed. Your WSL Ubuntu terminal works the same way.

In this step, you will install Nano and Vim, the two terminal text editors used throughout this project. You will also create a project directory to keep your scripts organized.

In this step, get ready to:
  • Install Nano and Vim in your WSL Ubuntu environment.
  • Verify both editors work by checking their version numbers.
  • Create a project directory for your scripts and config files.
Open your terminal and install both editors

When a cloud engineer SSHs into a fresh EC2 instance, the first command is usually a package update. Your WSL Ubuntu terminal follows the same workflow.

  • Press the Windows key to open your search bar.
  • Type Ubuntu and press Enter to open your WSL Ubuntu terminal.

Your terminal might ask for your Ubuntu password when you use sudo. Type it and press Enter. The characters won't appear on screen as you type.

  • Update your package list by running this command:
sudo apt-get update

You should see lines appearing as your system downloads the latest package information.

The next command calculates what to install and asks you to confirm. When you see Do you want to continue? [Y/n], type Y and press Enter.

  • Install both editors by running this command:
sudo apt install nano vim

You should see installation progress messages. If either editor is already installed, the command confirms it is already up to date.

What do these commands do?

  • sudo runs a command with administrator privileges, just like using an admin account on a server.
  • apt-get update refreshes your system's list of available packages so it knows where to find the latest versions.
  • apt install nano vim downloads and installs both editors from Ubuntu's package repository.

Seeing a permission error?

  • Make sure you typed sudo at the start of the command. Without it, your system blocks the install.
  • If sudo asks for a password, enter the password you set when you first configured Ubuntu in WSL.
  • If your password is not being accepted, make sure Caps Lock is off. Remember that no characters appear while you type it.

I'm getting a permission error when trying to install packages in WSL Ubuntu. How do I fix this?

Verify both editors are installed

A quick version check confirms each editor is ready to use.

  • Check that Nano is installed by running:
nano --version

You should see a version number and build details printed to the terminal.

  • Check that Vim is installed by running:
vim --version

You should see Vim's version number along with a list of included features.

Version check not working?

  • If you see a "command not found" message, go back and run the install command from the previous substep again.
  • Make sure you typed the command exactly as shown, including the two dashes before version.

I installed Nano and Vim but the version check is not working. What should I try?

Create your project directory

You need a dedicated folder to store the scripts and config files you will build in this project.

  • Create the project directory and move into it by running these commands:
mkdir ~/cloud-editor-lab
cd ~/cloud-editor-lab
  • Confirm you are in the right directory by running:
pwd

You should see a path ending in cloud-editor-lab.

Seeing 'cannot create directory'?

  • If the directory already exists from a previous attempt, that is fine. Run cd ~/cloud-editor-lab to move into it and continue.
  • If you see a different error, make sure the tilde (~) is included. It is a shortcut for your home directory.

I'm getting an error when creating my project directory in WSL. What should I do?

Your editing tools are installed and your project folder is ready. Next up, you will create your first script with Nano and run it to see real output.

Create Your First Script with Nano

Your terminal is set up with both editors installed and verified. Now it's time to create something you can actually run.

Cloud engineers constantly SSH into servers to write quick scripts for monitoring and troubleshooting. Nano is the fastest editor for this because it works like Notepad. You open it, you type, you save, and you're done.

In this step, get ready to:
  • Write a server information script using Nano.
  • Make the script executable and run it to see your system details.
Open Nano and write your server info script

Nano is a modeless editor. The moment it opens, you can start typing. No special keys, no modes to switch between.

  • Create a new file called server-info.sh by opening it in Nano. Run this command:
nano server-info.sh

What do you see?

Nano opens with a blank editing area. The top bar shows the program name and the file name. The bottom two lines show available keyboard shortcuts.

In those shortcuts, the ^ symbol means Ctrl. For example, ^O means Ctrl+O. You don't need to memorize anything because the shortcuts are always visible on screen.

  • Type the following script into the Nano editor. Your cursor is already in the right place. Type each line exactly as shown, pressing Enter at the end of each line:
#!/bin/bash
echo "=== Server Information ==="
echo "Hostname: $(hostname)"
echo "User: $(whoami)"
echo "Date: $(date)"
echo "Uptime: $(uptime -p)"
echo "OS: $(lsb_release -d | cut -f2)"
echo "=== Disk Usage ==="
df -h /
echo "=== Memory Usage ==="
free -h

What does this script do?

The #!/bin/bash line at the top is called a shebang. It tells Linux to run this file with the Bash shell.

Each echo line prints a label followed by a command's output. hostname gives the system name. whoami gives the current user. uptime -p shows how long the system has been running.

The last two sections use df -h / for disk usage and free -h for memory usage. The -h flag makes the numbers human-readable (gigabytes instead of raw bytes).

Now save the file and exit Nano.

  • Press Ctrl+O to save. Nano will display File Name to Write: at the bottom of the screen with your filename already filled in.
  • Press Enter to confirm the filename.
  • Press Ctrl+X to exit Nano. You're back in your normal terminal.
  • Verify the file was saved correctly by viewing its contents:
cat server-info.sh

You should see the full script you just typed printed in the terminal, starting with #!/bin/bash and ending with free -h.

File looks empty or different?

  • If cat shows nothing, you may have exited Nano with Ctrl+X before saving with Ctrl+O. Reopen the file with nano server-info.sh and try again.
  • Check for typos, especially in the $(...) sections. Every opening parenthesis needs a matching closing one.
  • Help me fix my server-info.sh file in Nano.

✔️ Awesome, I've got everything!

Great. Make sure you've saved server-info.sh and that cat shows all 11 lines of your script.

ⓧ I'd like to double check the full code

Here's the complete server-info.sh file. Compare it with your cat output line by line. If anything is different, reopen the file with nano server-info.sh and fix it.

#!/bin/bash
echo "=== Server Information ==="
echo "Hostname: $(hostname)"
echo "User: $(whoami)"
echo "Date: $(date)"
echo "Uptime: $(uptime -p)"
echo "OS: $(lsb_release -d | cut -f2)"
echo "=== Disk Usage ==="
df -h /
echo "=== Memory Usage ==="
free -h
Make the script executable and run it

Linux doesn't let you run a file as a program by default. You need to grant it execute permission first using chmod.

  • Make your script executable by running this command:
chmod +x server-info.sh

What does chmod +x do?

chmod changes file permissions on Linux. The +x flag adds execute permission, which tells Linux this file is allowed to run as a program.

Without this step, running ./server-info.sh would give you a Permission denied error.

Before you run the script, think about what you expect to see. Which pieces of system information do you think will print?

  • Run your script by executing this command:
./server-info.sh

Your terminal prints your hostname, username, current date, uptime, OS name, disk usage, and memory usage, all organized under labeled sections.

Seeing Permission denied or command not found?

  • If you see Permission denied, you may have skipped the chmod +x step. Run chmod +x server-info.sh and try again.
  • If you see No such file or directory, make sure you are in the ~/cloud-editor-lab directory. Run pwd to check your current location.
  • If the script runs but shows errors in the output, check your echo lines for missing quotation marks or mismatched parentheses. Reopen the file with nano server-info.sh to fix any typos.
  • Help me debug my server-info.sh script.

You just created and ran a real server information script using Nano. That whole workflow, open, type, save, run, is exactly how cloud engineers write quick scripts on live servers. Next up, you'll open this same file in Vim and discover why that editor trips up everyone the first time.

Survive the Vim Trap

You have a working script that prints server information, built entirely with Nano. Creating it felt straightforward because Nano works the way any text editor does.

Every AWS tutorial tells you to "edit the file with vi." You follow the instruction, the file opens, and you try to type. Nothing works the way you expect. This step puts you in that exact scenario so you learn to survive it.

In this step, get ready to:
  • Experience firsthand what happens when you open a file with vi and try to type.
  • Learn the correct way to enter, edit, and exit Vim.
  • Add a new line to your script using Vim and confirm it works.
Open your script with vi and try to type
  • Open your existing server-info.sh with the vi command by running:
vi server-info.sh

Your file is now open in vi. Before you touch the keyboard, what do you think will happen when you start typing?

  • Try typing some text, like echo "hello". Do not press any other keys first.
  • Watch what happens on screen as you press each key.

The characters do not appear the way you expect. Keys trigger unexpected behavior instead of inserting text. The cursor jumps around, lines shift, and nothing you type shows up where it should.

  • Press Esc several times to get back to a safe state.
  • Type :q! and press Enter to force-quit without saving any changes.

You are back at your terminal prompt. Your file is safe because you quit without saving.

What just happened?

You just experienced mode confusion. Vim is a modal editor, which means it behaves differently depending on which mode you are in.

Vim starts in Normal mode, where every key is a command instead of text input. When you pressed h, Vim moved the cursor left. When you pressed l, it moved right. None of those keys inserted text because Vim was not in Insert mode.

This is the exact scenario that trips up every cloud engineer on a real server. Now you know the escape hatch: press Esc to get back to Normal mode, then :q! to force-quit.

Still stuck inside vi?

If typing :q! shows the characters on screen instead of quitting, you are still in Insert mode. Press Esc first, then type :q! and press Enter.

If you are not sure what mode you are in, press Esc multiple times. It always returns you to Normal mode.

Still stuck? Help me get out of Vim

Reopen the file and edit with Insert mode

Now that you know the trap, here is the fix. You need to tell Vim you want to type text by entering Insert mode before you start typing.

  • Reopen your script in Vim by running:
vim server-info.sh
  • Press i on your keyboard.
  • Look at the bottom of the screen. You should see -- INSERT -- appear. This confirms Vim is now in Insert mode and ready for you to type.
  • Use the arrow keys to move your cursor to the end of the line that says echo "OS: $(lsb_release -d | cut -f2)".
  • Press Enter to create a new blank line.
  • Type this new line on the blank line:
echo "Kernel: $(uname -r)"

What does this line do?

The uname -r command prints the Linux kernel version. Kernel version is one of the first things you check when diagnosing server issues or confirming compatibility with a package.

  • Press Esc to return to Normal mode. The -- INSERT -- label at the bottom disappears.
  • Type :wq and press Enter to save and quit.

What is the difference between :q! and :wq?

Both commands start with : which opens Vim's command line from Normal mode.

  • :q! means "quit and throw away all changes." You used this to escape the trap safely.
  • :wq means "write (save) the file, then quit." This is the command you will use most often.

Seeing :wq appear as text on screen?

This means you typed :wq while still in Insert mode. Press Esc first to return to Normal mode, then use u to undo the accidental text. Then type :wq and press Enter.

Need help? Help me save and exit Vim

Run the updated script

Before you run the script, what new piece of information do you expect to see in the output?

  • Run your updated script by running:
./server-info.sh

You should see all the previous output plus a new Kernel: line showing your Linux kernel version, printed right after the OS information.

✔️ Awesome, I've got everything!

Great. Double check you have saved server-info.sh and that all the output lines are present.

ⓧ I'd like to double check the full code

Here is the complete server-info.sh file. Compare your version against this:

#!/bin/bash
echo "=== Server Information ==="
echo "Hostname: $(hostname)"
echo "User: $(whoami)"
echo "Date: $(date)"
echo "Uptime: $(uptime -p)"
echo "OS: $(lsb_release -d | cut -f2)"
echo "Kernel: $(uname -r)"
echo "=== Disk Usage ==="
df -h /
echo "=== Memory Usage ==="
free -h

Don't see the Kernel line?

  • Check that you saved with :wq and not :q!. Using :q! throws away your changes.
  • Verify the file contents by running cat server-info.sh. Look for the echo "Kernel: $(uname -r)" line between the OS line and the Disk Usage header.
  • If the line is missing, reopen the file with vim server-info.sh and add it again. Remember: press i first, make your edit, then Esc followed by :wq.

Need a hand? Help me fix my server-info.sh script

You survived the Vim trap and made your first edit. You now have the three most important Vim commands in your toolkit: i to type, Esc to stop typing, and :wq to save and leave. Next up, you will unlock Vim's real power: Normal mode commands that let you navigate and edit a long config file without ever touching Insert mode.

Navigate a Config File with Vim

In Step 3, you conquered the Vim trap. You can enter Insert mode with i, return to Normal mode with Esc, force-quit with :q!, and save-and-quit with :wq.

Insert mode alone is painfully slow for real config files. A production server might have a 200-line nginx.conf or sshd_config. Scrolling line by line to find one setting is painful. Vim's Normal mode commands let you jump, search, and delete instantly.

In this step, get ready to:
  • Create a realistic multi-section config file using a here document.
  • Navigate the file with Vim Normal mode power commands like search, line numbers, and jump-to-line.
  • Make five targeted edits without scrolling line by line.
Create a sample config file with a here document

You need a realistic multi-section config file to practice navigating. Typing it line by line in Vim would take ages and distract from the actual skill you are learning.

A here document lets you create a multi-line file in one terminal command. Everything between EOF markers gets written to the file.

  • Create your config file by pasting this entire command into your terminal:
cat << 'EOF' > app.conf
# Application Configuration
# Last updated: 2026-08-18

[server]
host = 0.0.0.0
port = 8080
max_connections = 100
timeout = 30

[database]
host = localhost
port = 5432
name = myapp_db
user = admin
password = changeme

[logging]
level = INFO
file = /var/log/myapp/app.log
max_size = 10MB
backup_count = 5

[security]
ssl_enabled = false
allowed_origins = *
rate_limit = 100
EOF

What does this command do?

cat << 'EOF' > app.conf tells the shell to write everything that follows into a file called app.conf, until it hits the line that says EOF.

The single quotes around EOF prevent the shell from interpreting any special characters inside. This file mirrors real Linux config files like systemd units or application settings.

  • Verify the file was created by running:
cat -n app.conf

You should see the full config file printed with line numbers on the left side. Notice it has four sections: [server], [database], [logging], and [security].

Don't see the file?

Make sure you pasted the entire command including the final EOF line on its own. If your terminal is still waiting for input (showing > instead of $), type EOF on a new line and press Enter.

Also confirm you are in the ~/cloud-editor-lab directory by running pwd.

Need more help? Help me troubleshoot my here document in WSL Ubuntu

Navigate the config file with Vim Normal mode

Now you will open this file in Vim and learn the Normal mode commands that make editing long config files fast. Each command you try produces an immediate, visible result in the editor.

  • Open the config file in Vim by running:
vim app.conf

Vim opens in Normal mode. Your cursor is at the top of the file. Time to try the power commands.

  • Type :set number and press Enter. Line numbers appear on the left side of every line.
  • Press G (capital G). Your cursor jumps straight to the last line of the file.
  • Press gg (two lowercase g's). Your cursor jumps back to line 1.
  • Type /port and press Enter. Vim jumps to the first match of "port" in the file, which is the server port line.
  • Press n. Vim jumps to the next occurrence of "port", which is the database port line. Press n again to see it cycle through all matches.

Why these commands change everything

Without these commands, finding a setting in a 200-line config file means pressing the down arrow key hundreds of times. With /port you jump there instantly. With G and gg you bounce between the top and bottom of any file in a single keystroke.

Make targeted edits to five settings

You are still inside Vim with app.conf open. Now you will combine search with a new Normal mode command to change specific values without scrolling.

The cw command means "change word." It deletes from your cursor to the end of the word and drops you into Insert mode so you can type the replacement. Press Esc when you are done.

  • Type /8080 and press Enter. Vim jumps to 8080 on the server port line.
  • Type cw. The word 8080 disappears and you are now in Insert mode.
  • Type 3000 and press Esc to return to Normal mode. The port is now 3000.

You just made your first targeted edit without scrolling. Now repeat the same pattern for the next three changes.

  • Type /changeme and press Enter. Vim jumps to the database password.
  • Type cw, then type s3cure_p@ss and press Esc.
  • Type /false and press Enter. Vim jumps to ssl_enabled.
  • Type cw, then type true and press Esc.
  • Type /INFO and press Enter. Vim jumps to the logging level.
  • Type cw, then type DEBUG and press Esc.

Four changes done. The last edit uses a different command: dd to delete an entire line.

  • Type /allowed and press Enter. Vim jumps to the allowed_origins line.
  • Type dd. The entire line disappears.

What just happened?

You made five targeted edits to a config file without scrolling through it once. Here is the pattern you used:

  • /value to jump straight to the thing you want to change.
  • cw to delete the old value and enter Insert mode in one move.
  • dd to delete an entire line you do not need.
  • Save and exit Vim by typing :wq and pressing Enter.

Before you check your work, think about what you expect to see. The server port should be 3000, the password should be s3cure_p@ss, SSL should be enabled, the log level should be DEBUG, and the allowed_origins line should be completely gone. Do you think all five edits stuck?

  • Verify your edits by running:
cat -n app.conf

You should see the file with line numbers. Confirm these five changes: port is 3000, password is s3cure_p@ss, ssl_enabled is true, level is DEBUG, and the allowed_origins line is gone.

One of the values looks wrong?

If a value has extra characters or is missing letters, you may have had your cursor in the wrong position when you typed cw. The cw command only changes from the cursor to the end of the current word. Make sure the search (/8080, /changeme, etc.) landed your cursor on the first character of the value before you pressed cw.

If the allowed_origins line is still there, you may have accidentally pressed d only once instead of twice. The dd command requires two quick presses.

You can fix any mistake by reopening the file with vim app.conf, searching for the value that is wrong, and correcting it.

Need more help? Help me fix my Vim edits in app.conf

✔️ Awesome, I've got everything!

Double check you have saved your file. Your app.conf is ready to go.

ⓧ I'd like to double check the full code

Here is what your app.conf should look like after all five edits. Compare it against your cat -n app.conf output.

# Application Configuration
# Last updated: 2026-08-18

[server]
host = 0.0.0.0
port = 3000
max_connections = 100
timeout = 30

[database]
host = localhost
port = 5432
name = myapp_db
user = admin
password = s3cure_p@ss

[logging]
level = DEBUG
file = /var/log/myapp/app.log
max_size = 10MB
backup_count = 5

[security]
ssl_enabled = true
rate_limit = 100

You just edited a multi-section config file in seconds using search, change word, and delete line. On a real server, this is the difference between a 10-minute scroll-and-hunt and a 30-second surgical fix. Next up, you will combine everything you have learned to build a real server health check script entirely in Vim.

Build a Server Health Check Script

In the last step, you used Vim's Normal mode to navigate and edit a multi-section config file in seconds. Now you know how to write text with Insert mode AND move through files efficiently with Normal mode.

Time to combine both skills into a real deliverable. Cloud engineers regularly write scripts on servers to monitor system health. In this step, you will build a health check script entirely in Vim that logs diagnostics to a file.

In this step, get ready to:
  • Write a bash health check script in Vim using Insert mode.
  • Verify the script using Normal mode commands like search and line numbers.
  • Run the script and view a timestamped health check log.
Open Vim and start writing the health check script

This script will collect system information, disk usage, memory stats, top processes, and network addresses, then write everything to a log file. Instead of printing directly to the terminal like server-info.sh did, this script uses output redirection to save results to a file.

  • Open a new file in Vim by running this command:
vim healthcheck.sh
  • Press i to enter Insert mode.
  • Confirm you see -- INSERT -- at the bottom of your screen.
  • Type the following code. This is the script header, timestamp, and system information section:
#!/bin/bash
LOG_FILE="healthcheck.log"

echo "=== Health Check Report ===" > "$LOG_FILE"
echo "Date: $(date)" >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- System ---" >> "$LOG_FILE"
echo "Hostname: $(hostname)" >> "$LOG_FILE"
echo "Uptime: $(uptime -p)" >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

What does this code do?

LOG_FILE="healthcheck.log" stores the output filename in a variable so you only need to change it in one place.

The > on the first echo creates the file fresh (overwriting any old log). Every line after that uses >> to append without erasing what came before.

Look at your Vim buffer. You should see 11 lines of code starting with the shebang line and ending with the system section.

  • Continue typing directly below your last line. Leave a blank line after the last echo "", then type the remaining sections:

echo "--- Disk Usage ---" >> "$LOG_FILE"
df -h / >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Memory ---" >> "$LOG_FILE"
free -h >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Top 5 Processes by Memory ---" >> "$LOG_FILE"
ps aux --sort=-%mem | head -6 >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Network ---" >> "$LOG_FILE"
ip addr show | grep "inet " >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "Health check complete. Results saved to $LOG_FILE"
cat "$LOG_FILE"

What do these sections collect?

  • df -h / reports disk usage for the root filesystem in human-readable format.
  • free -h shows memory and swap usage.
  • ps aux --sort=-%mem | head -6 lists the top 5 processes consuming the most memory (plus the header row).
  • ip addr show | grep "inet " filters for lines showing IP addresses assigned to your network interfaces.
  • The last two lines print a confirmation message and display the entire log file in the terminal.
Verify your script in Normal mode

Before saving, use Normal mode to double check your work. This is the same workflow you would use on a production server before committing a change.

  • Press Esc to return to Normal mode.
  • Confirm that -- INSERT -- has disappeared from the bottom of the screen.
  • Type :set number and press Enter to show line numbers. You should see 30 lines total.
  • Type /LOG_FILE and press Enter to search for the variable name.
  • Press n repeatedly to jump through every occurrence. This confirms the variable is used consistently throughout the script.

Spot a typo?

Press i to go back into Insert mode, fix the mistake, then press Esc to return to Normal mode. If you accidentally made a change you did not want, press u in Normal mode to undo it.

  • Once your script looks correct, save and quit by typing :wq and pressing Enter.

You are back in the terminal. The file is saved.

Still stuck inside Vim?

  • Press Esc a few times to make sure you are in Normal mode, then type :wq and press Enter.
  • If you see an error about unsaved changes and want to discard your work and start fresh, type :q! to force-quit, then reopen the file with vim healthcheck.sh.

Help me exit Vim and save my health check script.

✔️ Awesome, I've got everything!

Great. Double check you have saved the file before moving on.

ⓧ I'd like to double check the full code

Here is the complete healthcheck.sh file. Compare it to what you typed. If you need to fix anything, reopen the file with vim healthcheck.sh and make your edits.

#!/bin/bash
LOG_FILE="healthcheck.log"

echo "=== Health Check Report ===" > "$LOG_FILE"
echo "Date: $(date)" >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- System ---" >> "$LOG_FILE"
echo "Hostname: $(hostname)" >> "$LOG_FILE"
echo "Uptime: $(uptime -p)" >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Disk Usage ---" >> "$LOG_FILE"
df -h / >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Memory ---" >> "$LOG_FILE"
free -h >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Top 5 Processes by Memory ---" >> "$LOG_FILE"
ps aux --sort=-%mem | head -6 >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "--- Network ---" >> "$LOG_FILE"
ip addr show | grep "inet " >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

echo "Health check complete. Results saved to $LOG_FILE"
cat "$LOG_FILE"
Run the health check
  • Make the script executable by running this command:
chmod +x healthcheck.sh

Before you run the script, what do you think will happen? Will the output appear in the terminal, in a file, or both?

  • Run the health check script by running this command:
./healthcheck.sh

The script writes everything to healthcheck.log first, then the last line (cat "$LOG_FILE") dumps the entire log to your terminal. You get both: a saved file AND a live preview.

  • Confirm the log file was created by running:
cat healthcheck.log

You should see a full health check report with a timestamp at the top, followed by system info, disk usage, memory stats, top 5 processes by memory, and network addresses.

Seeing "Permission denied" or missing output?

  • If you see a permission error, make sure you ran chmod +x healthcheck.sh before executing the script.
  • If a section is missing from the log, reopen the file with vim healthcheck.sh and compare your code to the full version in the double-check tab above.
  • Check that every line after the first echo uses >> (append), not > (overwrite). Using > on later lines erases everything above it.

Help me debug my health check script.

Secret mission

Customize Your Shell with .bashrc

You've edited practice files and scripts throughout this project. Now it's time to edit a live system file that controls how your terminal looks and behaves. Can you customize .bashrc with Vim to add shortcuts and a colored prompt?

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely inside your WSL Ubuntu environment, so there are no ongoing costs. Decide whether to keep your project files and shell customizations, revert your changes, or remove everything.

Resources you used:

  • ~/cloud-editor-lab directory containing server-info.sh, app.conf, healthcheck.sh, and healthcheck.log.
  • Custom aliases and PS1 prompt added to ~/.bashrc.
  • Backup file at ~/.bashrc.bak.

Keep everything running

No action needed. Choose this if you plan to keep practicing with your scripts or want your custom shell aliases available in future terminal sessions.

  • Your scripts in ~/cloud-editor-lab stay ready to run anytime.
  • Your custom aliases (ll, cls, myip, diskcheck, memcheck) remain active in every new terminal session.
  • Vim and Nano remain installed as standard Linux utilities. They take up minimal disk space and are useful for any future cloud engineering work.

Pause - I'll come back to this later

Revert your shell customizations to their defaults while keeping your project files for later.

  • Restore your original ~/.bashrc from the backup you created by running:
cp ~/.bashrc.bak ~/.bashrc
source ~/.bashrc
  • Your terminal prompt and aliases revert to their defaults.
  • Your project files in ~/cloud-editor-lab stay intact for when you return.
  • Your backup at ~/.bashrc.bak stays in place in case you need it again.

Delete - I don't want to use this again

Remove all project files and revert your shell to its original state.

  • Restore your original ~/.bashrc and reload your shell by running:
cp ~/.bashrc.bak ~/.bashrc
source ~/.bashrc
  • Remove the backup file by running:
rm ~/.bashrc.bak
  • Delete the project directory and all its files by running:
rm -rf ~/cloud-editor-lab
  • Vim and Nano remain installed as standard Linux utilities. They do not consume resources when not in use and are useful for future cloud work.

Nice Work!

Nice Work!

You just built a complete Linux terminal editing workflow using both Nano and Vim. The next time you SSH into an EC2 instance and a tutorial says "edit the file with vi," you will know exactly what to do.

You've learned how to:

  • Create and run bash scripts using terminal text editors, from a quick server info script in Nano to a full health check tool built entirely in Vim.
  • Survive Vim's modal editing by mastering the i / Esc / :wq workflow and escaping safely with :q!.
  • Navigate and edit multi-section configuration files using Vim's Normal mode power commands like search, line numbers, delete line, and jump-to-line.
  • Secret Mission: Customize your shell environment by editing .bashrc with Vim to add aliases and a custom prompt, proving you can safely modify live system config files.

Ready to quiz yourself?