find . -type f -name "*.php"Example: Useful when you need every matching file under the current directory tree.
Gotcha: Shell quoting matters. Quote the pattern so the shell does not expand it before `find` runs.
This page focuses on common Bash work you need in day-to-day development: file inspection, filtering, loops, variables, and text processing.
find . -type f -name "*.php"Example: Useful when you need every matching file under the current directory tree.
Gotcha: Shell quoting matters. Quote the pattern so the shell does not expand it before `find` runs.
grep -R "CheatsheetController" .Example: Use this when you need a quick recursive search and `rg` is not available.
Gotcha: For large repos, `rg` is usually faster and cleaner. This stays useful as a portable fallback.
grep -R "Route::get" routes | wc -lExample: Useful for quick inventory tasks when you care about totals more than the raw lines.
Gotcha: Counts reflect matching lines, not unique files or unique symbols.
backup_dir="/tmp/coderstool_backup"
echo "$backup_dir"Example: Helpful in scripts where you reuse a path, environment name, or branch value more than once.
Gotcha: Do not put spaces around `=` in Bash variable assignment.
for file in storage/app/cheat-library/*.json; do
echo "$file"
doneExample: A practical pattern when you want to inspect or process each matching file in turn.
Gotcha: Globs that match nothing can behave differently depending on shell options. Test on an empty directory before using in automation.
Bash is still the fastest way to connect small operations into a repeatable workflow. You reach for it when a GUI is too slow, when you need to inspect a directory tree, or when a one-line pipeline can answer a question faster than opening an IDE. This page focuses on the Bash moves that show up in real development work: file inspection, filtering, loops, variables, quoting, and redirection.
Treat this as a practical Bash reference, not a complete Bash Reference Manual. The goal is to make common shell tasks easy to recall and safe to adapt. If you have ever searched for bash(1), GNU Bash, or a compact Bash cheat sheet, this page is the action-oriented version: enough detail to work confidently, without a long detour through full documentation.
| Task | Pattern | Why it matters |
|---|---|---|
| List files with details | ls -lah |
Quick view of size, permissions, and hidden files |
| Search recursively | grep -R "needle" . |
Fast text lookup across a project |
| Find files by name | find . -name "*.log" |
Safer than manual browsing for repetitive file discovery |
| Count lines or results | wc -l |
Useful at the end of a pipeline |
| Redirect stdout and stderr | cmd > out.log 2>&1 |
Capture everything from a command in one place |
| Loop over files | for f in *.json; do ...; done |
Repeat the same action without copy-paste |
| Read command output into a variable | count=$(grep -R "TODO" . | wc -l) | Keep shell scripts composable |
| Chain commands conditionally | build && deploy | Stop a workflow early if a step fails |
```bash
project_dir="$HOME/projects/app"
cd "$project_dir"
echo "Searching for TODO comments..."
todo_count=$(grep -R "TODO" src | wc -l)
echo "Found $todo_count TODO entries"
for file in config/*.yaml; do
echo "Checking $file"
grep -n "timeout" "$file"
done > review.log 2>&1
```
This snippet shows several Bash habits worth keeping together: quote variables that may contain spaces, use command substitution for a small derived value, and redirect both standard output and standard error when you want a durable log. Bash gets risky when you type quickly and assume the shell will “do what you mean.” A good reference keeps those assumptions visible.
Most Bash mistakes are not about syntax memorization. They come from expansion rules. Double quotes allow variable expansion while protecting whitespace. Single quotes prevent expansion entirely. Unquoted variables can split on spaces and wildcard characters, which is often not what you want in scripts.
Use variables when they remove duplication or make a script easier to read, not just because Bash allows them. For example, log_dir="/var/log/myapp" is useful because you may reuse the path three or four times. By contrast, storing every short literal in a variable usually makes a one-liner harder to scan. The sweet spot is clarity.
If you need a Bash reference for constructs used in scripts, keep these ideas in mind:
$(...) is the modern, readable way to capture command output."$var" is the safe default when expanding a variable."$@" passes script arguments as distinct values.[[ ... ]] is usually more predictable than legacy test syntax in non-portable Bash scripts.Pipelines move the standard output of one command into the standard input of the next. Redirection sends output somewhere else: a file, /dev/null, or another stream. Many shell questions come down to understanding these two tools clearly.
The most common example is 2>&1. In Bash, file descriptor 1 is standard output and 2 is standard error. Writing 2>&1 means “send stderr to wherever stdout is going right now.” So this command:
```bash
my_command > build.log 2>&1
```
puts both normal output and errors into build.log. That is why the ordering matters. If you reverse the pieces carelessly, you may not capture what you expect. This is also why many Bash references answer “what means 2>&1?” before they explain more advanced scripting features. It shows up everywhere.
Bash is excellent for orchestration, glue code, file-oriented loops, and command composition. It is not always the best choice for large business rules, complex data modeling, or cross-platform GUI-heavy workflows. A script that starts as five lines and quietly grows into five hundred lines usually wants a different home.
That does not mean Bash scripting is awful. It means Bash is sharp. Use it where shell semantics are an advantage:
If the workflow stays close to the command line, Bash remains hard to beat.
| Mistake | Why it breaks | Better habit |
|---|---|---|
| Unquoted paths | Spaces and globbing can split arguments | Quote variables and literal paths when in doubt |
Parsing ls output in scripts |
Output is display-oriented, not stable data | Use find, globs, or shell loops directly |
| Writing giant one-liners too early | Hard to debug and maintain | Start multiline, then compress if needed |
| Ignoring exit codes | Downstream steps may run after a failure | Use &&, set -e carefully, or explicit checks |
| Mixing shell dialects | POSIX sh and Bash are not the same |
Use Bash features only when the script is Bash |
A Bash reference is a compact map of command shapes, expansion rules, operators, and examples you can apply quickly. It is most useful when you remember the job but not the exact syntax.
The full sources are the Bash manual, the bash(1) man page, and GNU Bash documentation. Use those when you need edge-case semantics. Use a page like this when you need the working pattern first.
Not when it stays in its natural range. Bash is great for automation close to the shell. It becomes painful when a problem needs richer data structures, strong typing, or complex application logic.
2>&1 mean?It redirects standard error to the same destination as standard output. In practice, it is how you capture both normal output and errors in one stream or one log file.
After you have the shell shape you need, use the Linux command reference for deeper system inspection, the Git reference for repository recovery and diffs, the YAML reference for config structure examples, or the Postgres reference for database-side command workflows. The point is to keep moving from syntax recall to real execution.
Programming can be fun, so can cryptography; however they should not be combined.
…
…