3.3 Create and Edit Text Files

Almost every RHCSA objective eventually reduces to creating or editing a text file in the right place with the right content, then making related services or permissions correct so the result survives reboot. Shells, package tools, and systemd matter—but if you cannot reliably open, change, save, and verify a file under time pressure, later topics become unnecessarily hard.

Creating Files Without an Interactive Editor

You do not always need vim. Quick creation methods:

touch /tmp/notes.txt              # empty file (or update timestamps)
echo 'servera' > /tmp/hostname-hint.txt
echo 'line two' >> /tmp/hostname-hint.txt   # append
cat > /tmp/motd-snippet.txt << 'EOF'
Welcome to the lab system.
EOF

Redirection review (ties to essential shell skills):

Danger: > on an existing config file wipes it. For live /etc files, prefer an editor with an explicit save, or write to a temp file and mv into place after review.

Create directories first when needed:

mkdir -p ~/lab/configs
printf 'PermitRootLogin no\n' > ~/lab/configs/sshd-snippet.conf

Choosing an Editor on the Exam

RHEL provides multiple editors. For EX200, fluency in one reliable terminal editor is enough; many candidates standardize on vim (or vi) because it is always expected on minimal systems. nano is friendlier if installed and allowed in your lab image—confirm with command -v nano.

You are not graded on editor fandom. You are graded on the resulting file content and system behavior.

vim Essentials for RHCSA

vim (and vi) is modal.

Modes you must know

Survival cheatsheet

vim /etc/hosts
  i          insert text
  Esc        back to normal mode
  :w         write (save)
  :q         quit
  :wq  or ZZ save and quit
  :q!        quit discarding changes
  dd         delete current line (normal mode)
  x          delete character under cursor
  /ssh       search forward for ssh
  n          next search match
  u          undo

Open at a line if you know it: vim +42 /etc/ssh/sshd_config.

If you accidentally enter a mode you do not understand, press Esc until you are calm, then :q! to abandon or :wq to save intentionally. Panic-quit without saving can lose work; panic-save of a half-edited sshd_config can lock you out—use sshd -t after SSH edits when that file is in play.

Minimal visual workflow

1. vim file
2. Move with arrows or h j k l
3. i → type → Esc
4. :wq
5. cat -n file or grep to verify

That five-step loop is enough for most exam edits.

nano Essentials

If nano is available:

nano /etc/hosts

Shortcuts are shown at the bottom (^ means Ctrl):

• Ctrl+O — write out (save); confirm filename
• Ctrl+X — exit (prompts if unsaved)
• Ctrl+W — search
• Ctrl+K / Ctrl+U — cut / paste line-oriented workflow

nano stays in a single modeless-style editing experience, which some candidates prefer under stress. Either editor is fine; pick one and practice until saving is automatic.

Paths, Tilde, and Root’s Home

Shell expansion of ~ depends on the current user:

Mistakes that cost time:

• Creating authorized_keys under /home/root (wrong; does not exist by default)
• Editing ~/my.conf as root thinking it is the same file student created earlier
• Using relative paths after cd somewhere unexpected

Always:

whoami
echo $HOME
pwd
realpath ./file   # when available, resolve absolute path

System configuration almost always lives under /etc, unit files under /etc/systemd/system, and application data in documented paths—not in a random home directory—unless the task explicitly says otherwise.

Editing for Persistence After Reboot

Creating a file in /tmp is often non-persistent across reboot (tmpfs or cleanup policies). Exam tasks that must remain after reboot usually require files in durable locations:

Workflow for a persistent service-related edit:

1. Edit the correct file with vim/nano
2. Validate syntax if a tool exists (sshd -t, nginx -t, systemd-analyze verify, etc.)
3. systemctl enable and/or restart/reload as required
4. Confirm with systemctl status and a functional test
5. Mentally (or literally) ensure a reboot would still load that unit and file

The file content alone does not start a service; enabled units + correct on-disk config produce post-reboot behavior.

Permissions and Safety While Editing

• Ordinary users cannot write most of /etc; use root (su - or sudo) when required.
• Avoid leaving world-writable config files.
• For critical files, copy a backup first: cp -a /etc/ssh/sshd_config /root/sshd_config.bak
• Use visudo for sudoers (special validation)—do not casually vim /etc/sudoers without the wrapper when policy tools exist.

View files safely:

less /var/log/messages
cat -A file          # show tabs/line endings when debugging weird parse errors
grep -n Pattern file

Practical Exam Patterns

Pattern A — Create a required file with exact content

cat > /etc/issue.d/lab.issue << 'EOF'
Authorized use only.
EOF

Pattern B — Change one directive in a large config

vim /etc/ssh/sshd_config
# set or adjust a directive, Esc, :wq
sudo sshd -t && sudo systemctl reload sshd

Pattern C — Drop-in override instead of editing vendor file

Many modern RHEL configs support .d directories. Prefer a small drop-in when the task allows clarity and safer upgrades—still a text file you create and edit.

Common Pitfalls

• Saving the file under the wrong path or wrong user’s home
• Forgetting to leave insert mode before :wq (vim beeps or inserts punctuation into the file)
• Using > and truncating a working configuration
• Editing only a runtime copy or tmp location that disappears after reboot
• Not verifying with cat/grep after the editor exits

Build muscle memory: open → edit → save → verify → enable/restart if needed. That loop is the daily language of RHCSA administration and the foundation for storage, networking, security, and software objectives that all depend on correct on-disk text.