If you’ve ever copied a Linux command from a tutorial and it didn’t work, you’re not alone.
Especially with I/O redirection (>, >>, pipes, 2>, etc.), one tiny typo or wrong character and everything breaks.

This guide walks through real mistakes from a Linux I/O redirection article and shows you how to fix them, step by step.
If you’re a small-business sysadmin, a VPS owner, or just the family “IT person”, this is for you.

---

1. Overwrite vs Append: Single vs Double Redirect

First common confusion: > vs >>.
In one article, it said:

“Commands with a single bracket do not overwrite the destination’s existing contents.”

That’s backwards.

Here’s how it really works:

• > overwrites the file (or creates it if it doesn’t exist).
• >> appends to the end of the file (or creates it if it doesn’t exist).

Safe test in your home directory

Step-by-step:

1. Open a terminal.
2. Go to a safe directory:
   bash
cd ~
3. Create a new file and write a line using >:
   bash
echo Written to a new file > data.txt
4. Check the contents:
   bash
cat data.txt
   You should see:
   Written to a new file
5. Append a new line using >>:
   bash
echo Appended to an existing file's contents >> data.txt
6. Check again:
   bash
cat data.txt
   Now you should see two lines, with the second line appended.

Why this matters:
– Use > when you want to replace the file content.
– Use >> when you don’t want to lose what’s already inside.

Safety tip: when working with logs or config backups, default to >> unless you are 100% sure you want to overwrite.

---

2. Quotes That Break Commands: Smart Quotes vs Real Quotes

Another real-world issue from the article:

echo Appended to an existing file's contents >> data.txt
“This doesn’t seem to work unless you remove the ’”

What happened there is the classic smart quotes vs plain quotes problem.
Sometimes when commands are copied from web pages, ' turns into a curly apostrophe like ’.
Bash doesn’t understand that character as a valid quote.

How to spot and fix it

Bad (copied from a rich-text source):

echo Appended to an existing file’s contents >> data.txt
#                ^ this is a smart quote, not a plain apostrophe

Good (typed directly in your terminal):

echo Appended to an existing file's contents >> data.txt

Steps to fix when a copied command fails for no obvious reason:

1. Retype all quotes manually in the terminal:
2. Replace ’ and “ ” with ' and ".
3. Avoid pasting from rich-text apps (Word, some web editors, chat apps).
4. If you must copy, paste into a plain-text editor first (like nano, vim, or a basic text editor) to clean it.

Quick sanity check:
Run this to confirm your shell sees the right characters:

echo 'test'

If that works but your pasted command doesn’t, you probably have smart quotes.

---

3. Piping `find` to `grep`: The Missing Slash Problem

In the original example, they showed this pipe:

find /var lib | grep deb

Users reported an error:

find: 'lib': No such file or directory

The issue is simple but sneaky: missing /.

Correct command

Instead of:

find /var lib | grep deb

Use:

find /var/lib | grep deb

That extra slash / changes everything.

• find /var lib means: search /var and also search ./lib (relative path in current directory).
• find /var/lib means: search the directory /var/lib.

Since many systems don’t have a ./lib directory where you’re currently standing, find complains:

find: 'lib': No such file or directory

Step-by-step to verify

1. Run the broken example:
   bash
find /var lib | grep deb
   You’ll likely see some output (matching deb) plus the error.

2. Run the fixed one:
   bash
find /var/lib | grep deb
   Now you’ll get results without the find: 'lib' error.

Why this matters: when piping (command | command), make sure the first command is valid by itself before adding | grep.

Try:

find /var/lib

If that works without errors, then adding | grep something is safe.

---

4. `man` and `less`: Don’t Pipe When You Don’t Need To

The article suggested:

man tee | less

Someone correctly pointed out:

“man tee | less is bit redundant and also strip the colours and bold formatting. man already use less pager by default.”

This is one of those “technically works, but worse” patterns.

What’s really happening

• man tee already uses less (or a similar pager) internally.
• Piping man tee | less forces the output of the pager into another less.
• You often lose formatting (colors, bold, etc.).

What you should actually run

Just:

man tee

If you want to search inside man, you can:
– Press / then type your search term and hit Enter.
– Use n for next match, N for previous.

So if you see man something | less in a tutorial, you can drop the | less in almost all normal cases.

---

5. Redirecting Errors with 2>: They Do NOT Still Show

In the article, there was a description like this:

“This pattern redirects the standard error stream of a command to a file, overwriting existing contents.”
bash
mkdir '' 2> mkdir_log.txt
“This redirects the error raised by the invalid directory name ‘’, and writes it to log.txt. Note that the error is still sent to the terminal and displayed as text.”

The last sentence is wrong.
If you redirect stderr with 2>, the error does not show in the terminal.
It goes to the file or device you specify.

Try it yourself

1. Run an obviously broken command without redirection:
   bash
mkdir ''
   You’ll see an error message printed to your terminal (stderr).

2. Now redirect stderr to a file:
   bash
mkdir '' 2> mkdir_log.txt

3. What happens:

4. Terminal: no error shown.

5. File: the error text is saved in mkdir_log.txt.

6. Check the file:
   bash
cat mkdir_log.txt
   You’ll see the error message that used to appear in the terminal.

What 2> really does

• > redirects stdout (file descriptor 1) by default.
• 2> redirects stderr (file descriptor 2).
• When you use 2> file, stderr goes to file instead of the screen.

So the correct explanation of this pattern is:

This pattern redirects the standard error stream of a command to a file, overwriting existing contents. The error is not shown in the terminal anymore.

Safety tip: if you don’t want to lose previous errors, use 2>> to append instead of overwrite.

Example:

my_script.sh 2>> error_log.txt

---

6. Safe Habits When Copying Redirection Examples

Let’s wrap up with a small checklist you can use whenever you see redirection commands in a tutorial.
This saves you from subtle bugs like the ones we just fixed.

1) Test in a safe directory

Before running anything that uses > or >>:

cd ~
mkdir -p redir-test
cd redir-test

This keeps you away from system config files and important project files.

2) Double-check `>` vs `>>`

Ask yourself:

• Am I okay if this file is completely replaced? → use >.
• Do I want to keep existing content and just add more? → use >>.

If you’re not sure, start with >> in your tests.

3) Watch out for smart quotes

When copying from the web, watch for these characters in the command:

• Bad: ‘ ’ “ ”
• Good: ' "

If in doubt, just retype quotes and apostrophes manually in your terminal.

4) Validate the left side of the pipe first

For something like:

find /var/lib | grep deb

First run just:

find /var/lib

If that prints an error, fix it before adding | grep.

5) Remember what each redirect means

Quick mental map:

• > – send stdout to file, overwrite.
• >> – send stdout to file, append.
• 2> – send stderr to file, overwrite.
• 2>> – send stderr to file, append.
• | – send stdout of left command into stdin of right command.

If stderr still shows up when you use 2>, something is wrong with the command or the shell.

---

Need more help? Check the latest CrushEdge posts.