Command-Line Flags Reference
The same flag conventions appear in git, docker, kubectl, curl, rsync, npm, and most Unix tools. Learn them once, recognise them everywhere.
Last reviewed:
POSIX flag conventions
- Short flags use a single dash:
-r,-f,-v. Often stackable:-rf=-r -f. - Long flags use double dash:
--recursive,--force. Never stack. - Flags before arguments by convention:
rm -rf old/notrm old/ -rf(though most tools accept both). - Use
--to end flag parsing — useful when a filename starts with-:rm -- -weird-name.txt.
-r, -R, --recursive
Recursive
Apply the operation to every file in a directory tree, going into all sub-directories.
Examples
rm -r build/— Delete the build folder and everything inside it.cp -r src/ src-backup/— Copy a directory and its contents.grep -r "TODO" .— Search for "TODO" in every file under the current directory.chmod -R 755 public/— Set permissions on the folder and every file inside it.
How engineers say it: "recursive" or just "the dash-r flag"
⚠️ Order matters with some tools — rm -rf old/ is fine, but always type the path AFTER the flags, never with a leading slash by accident.
-f, --force
Force
Skip confirmation prompts and proceed even when the action would normally be blocked or warned about.
Examples
rm -f config.bak— Delete without prompting, even if the file doesn't exist.git push --force— Overwrite the remote branch — destructive on shared branches.docker rm -f web— Stop and remove a running container in one step.mv -f src.txt dst.txt— Overwrite destination without asking.
How engineers say it: "force" or "the force flag"
⚠️ git push --force on a shared branch can destroy other people's commits. Use --force-with-lease instead — it refuses to overwrite changes you have not seen.
-v, --verbose
Verbose
Print extra detail about what the command is doing. Useful for debugging.
Examples
rm -v *.tmp— Print every file being removed.curl -v https://example.com— Show request headers, response headers, and TLS handshake info.rsync -v src/ dst/— List every file being transferred.ssh -v user@host— Print debug output during the SSH connection.
How engineers say it: "verbose" or "with verbose output"
⚠️ Some tools use -vv or -vvv for increasing verbosity (Ansible, ssh). More v's = more output.
-q, --quiet, --silent
Quiet / Silent
Suppress non-essential output. Useful in scripts where you only care about the exit code.
Examples
grep -q "ERROR" log.txt— Returns exit code 0 if "ERROR" is found, no output.curl -s https://api/health— No progress bar, no errors — just the response body.rm -f --quiet bad.tmp— Silent removal (no message if file doesn't exist).
How engineers say it: "quiet" or "silent mode"
⚠️ In curl, -s also suppresses errors. Pair with -S to show errors but hide the progress bar: curl -sS.
-h, --help
Help
Print the command's usage information and exit.
Examples
git --help— List all git subcommands.docker run --help— Show options for docker run.curl -h— Show curl options.
How engineers say it: "the help flag" or "dash-help"
⚠️ -h sometimes means something else (e.g. du -h means "human-readable sizes"). When in doubt, use --help — the long form is consistent.
--dry-run, -n
Dry Run
Show what the command WOULD do without actually doing it. Critical safety flag for destructive operations.
Examples
rsync --dry-run -av src/ dst/— List files that would be transferred, transfer nothing.git push --dry-run— Show what would be pushed, push nothing.kubectl apply -f deploy.yaml --dry-run=client— Validate the manifest without applying it.npm publish --dry-run— Show what would be published without uploading.
How engineers say it: "dry run" or "dry run it first"
⚠️ Not all tools support --dry-run — rm notably does not. For destructive operations without dry-run support, redirect to a temp dir or use a find ... -print first to preview what would be affected.
-y, --yes, --assume-yes
Auto-Yes
Automatically answer "yes" to all confirmation prompts. Used in scripts where you can't respond interactively.
Examples
apt-get install -y nginx— Install without confirmation prompts.docker system prune -f— Use -f as "yes" — skip the "are you sure?" prompt.yes | npm install— Pipe the 'yes' command to answer Y to anything (legacy trick).
How engineers say it: "dash-y" or "auto-confirm"
⚠️ Be careful in CI scripts — auto-answering "yes" to every prompt can mask migration confirmations you actually wanted to see.
--no-X, --without-X
Negation flag
Disable a feature that is on by default.
Examples
git commit --no-verify— Skip pre-commit hooks.git merge --no-ff feature/x— Force a merge commit even when fast-forward is possible.docker build --no-cache .— Ignore the layer cache; rebuild every step.npm install --no-save— Install without writing to package.json.
How engineers say it: "with --no-cache" or "the no-verify flag"
⚠️ Bypassing checks like --no-verify is sometimes necessary for emergencies but is often a code smell — it usually means the hook is misconfigured, not the commit.
-i, --interactive
Interactive
Prompt for confirmation before each step instead of acting automatically.
Examples
rm -i *.log— Ask before deleting each log file.git rebase -i HEAD~5— Open an editor to reorder/squash the last 5 commits.docker run -it ubuntu bash— Attach an interactive terminal to the container.
How engineers say it: "interactive" or "interactive mode"
⚠️ In Docker, -it is the combination of -i (interactive) and -t (allocate a TTY). Use it whenever you want to type into the container.
-o, --output
Output
Specify where the command should write its output — a file, a format, or a directory.
Examples
curl -o page.html https://example.com— Write the response body to page.html.kubectl get pods -o yaml— Output in YAML format instead of the default table.docker build -o type=local,dest=./out .— Export the build result to a local directory.gcc -o myapp main.c— Name the compiled binary "myapp".
How engineers say it: "output to" or "with -o"
⚠️ In kubectl, -o yaml and -o json are essential for scripting — much easier to parse than the default human-readable table.
--version, -V
Version
Print the tool's version string and exit. Always useful when reproducing bugs.
Examples
node --version— Print Node.js version.docker -v— Print Docker version.git --version— Print Git version.
How engineers say it: "version" or "what version are you on?"
⚠️ Lowercase -v usually means "verbose"; uppercase -V or long-form --version is the safe way to ask for version.
-a, --all
All
Include everything — hidden files, stopped containers, tracked and untracked changes — instead of just the default subset.
Examples
ls -a— List hidden files too (anything starting with a dot).docker ps -a— Show every container, including ones that have exited.git add -A— Stage all changes — new, modified, and deleted files.git branch -a— List local AND remote-tracking branches.
How engineers say it: "dash-a" or "show me all of them"
⚠️ git add -a is not the same as git add -A — Git flags are case-sensitive. -A is the one that stages deletions too.
-p (context-dependent)
Port / Parents / Publish
One of the most overloaded short flags in CLI tooling — meaning depends entirely on the command.
Examples
mkdir -p src/components/auth— Create parent directories as needed, without erroring if they exist.ssh -p 2222 user@host— Connect on a non-default port.docker run -p 8080:80 nginx— Publish (map) container port 80 to host port 8080.scp -P 2222 file.txt user@host:— scp uses a capital -P for port — one of the classic gotchas.
How engineers say it: "dash-p" — always check the man page for what it means in that tool
⚠️ Never assume: -p means "parents" in mkdir, "port" in ssh, and "publish" in docker. scp even breaks convention with a capital -P for port.
-u, --upstream, --user
Upstream / User
Sets a tracking relationship or specifies which user/account an action runs as.
Examples
git push -u origin main— Push and set origin/main as the upstream — future git push needs no args.docker run -u 1000:1000 app— Run the container process as a specific UID:GID instead of root.curl -u user:pass https://api.example.com— Send HTTP Basic Auth credentials with the request.
How engineers say it: "set the upstream" or "run it as user 1000"
⚠️ Skipping -u on your first push means every future push/pull needs the branch name spelled out explicitly until you set it once.
-w, --watch
Watch
Keep the command running and re-run it (or refresh output) whenever the input changes.
Examples
npm run build -- --watch— Rebuild automatically whenever a source file changes.tsc --watch— Recompile TypeScript on every save.kubectl get pods --watch— Stream live updates as pod status changes, instead of a one-time snapshot.
How engineers say it: "run it in watch mode" or "watch the pods"
⚠️ Watch mode processes never exit on their own — remember to Ctrl+C them, especially in CI where a hung watcher will stall the pipeline until it times out.
-c, --count, --config
Count / Config
Another flag whose meaning shifts by tool — often "count the matches" or "use this config file".
Examples
grep -c "ERROR" server.log— Print the number of matching lines instead of the lines themselves.ssh -F custom_config -c aes256-ctr user@host— Specify the SSH cipher to use for the connection.docker --context prod ps— Run the command against a named remote Docker context.
How engineers say it: "dash-c" — confirm from --help whether it means count or config here
⚠️ Don't confuse grep -c (count of matching lines) with wc -l (count of all lines) — piping one into the other by mistake gives a meaningless number.
-x, --exclude, -x (trace)
Extract / Exclude / Trace
Extracts an archive, excludes a pattern from an operation, or turns on shell execution tracing — three unrelated meanings sharing one letter.
Examples
tar -xzf archive.tar.gz— Extract a gzip-compressed tar archive.rsync -av --exclude="*.log" src/ dst/— Sync everything except files matching the pattern.bash -x deploy.sh— Print every command as it executes — invaluable for debugging shell scripts.
How engineers say it: "run it with dash-x to see what's actually executing"
⚠️ In tar, mixing up -x (extract) and -c (create) overwrites nothing by itself, but running -c when you meant -x silently creates an empty-looking archive instead of unpacking one.
-t, --tag, -t (tty)
Tag / Allocate TTY
Labels a build artifact with a name, or allocates a pseudo-terminal for an interactive session.
Examples
docker build -t myapp:1.2.0 .— Tag the built image with a name and version.docker run -it ubuntu bash— The -t half of -it — allocates a terminal so the shell prompt renders correctly.git tag -a v1.2.0 -m "Release 1.2.0"— Create an annotated tag pointing at the current commit.
How engineers say it: "tag it as latest" or "run it with a tty attached"
⚠️ Forgetting -t in docker build means your image only has the default :latest tag — easy to accidentally overwrite a previous "latest" build with something untested.
English phrases engineers use
- "Always dry-run it first on destructive commands."
- "You'll need to
--forcethe push, but be careful — that branch is shared." - "Run it with -v so we can see what's failing."
- "The script passes -y to skip the confirmation prompt in CI."
- "Don't recursively chmod 777 — that opens every file to everyone."
- "
kubectl apply --dry-run=clientfirst, then apply for real."
Frequently Asked Questions
What is the difference between -v and --verbose?
-v is the short (single-dash) form and --verbose is the long (double-dash) form of the same flag — most CLI tools accept both as equivalent ways to request extra diagnostic output. Some tools like ssh and Ansible let you repeat the short form (-vv, -vvv) to increase verbosity further, which the long form does not support in the same stacked way.
What does a lone -- mean in a CLI command?
A standalone -- tells the command to stop parsing everything after it as flags, treating the remaining arguments as literal positional values. This matters when a filename or argument itself starts with a dash — for example rm -- -weird-name.txt deletes a file literally named "-weird-name.txt" instead of rm trying to interpret it as an unknown flag.
Why is git push --force considered risky, and what should be used instead?
--force overwrites whatever is on the remote branch with your local history, which can silently destroy commits a teammate pushed that you have not fetched yet. --force-with-lease is the safer alternative: it checks that the remote branch still matches what you last saw before overwriting it, and refuses to push if someone else has added commits you have not seen.
Why does -p mean something different in mkdir, ssh, and docker?
-p is one of the most overloaded short flags in CLI tooling because there is no cross-tool standard for single-letter flags — each tool's author picks what makes sense for that tool. In mkdir -p it means "create parent directories as needed"; in ssh -p it specifies a non-default port; in docker run -p it publishes (maps) a container port to the host. scp breaks the pattern entirely and uses a capital -P for port.
What is the difference between --dry-run and just being careful?
--dry-run makes a command print exactly what it would do — which files would be deleted, transferred, or applied — without actually performing the action, giving a safety preview before a destructive or hard-to-reverse operation. Not every tool supports it: rm notably has no --dry-run, so previewing what rm -rf would delete requires a workaround like running find with -print first.
What is the difference between -i and -it when running a Docker container?
-i (interactive) keeps STDIN open so you can send input to the container. -t allocates a pseudo-terminal (TTY) so that input and output render correctly, like an interactive shell prompt. The two are almost always combined as -it when you want to attach to a container and type commands into it, such as docker run -it ubuntu bash.
Is -a the same as -A when staging changes in Git?
No — Git flags are case-sensitive, and git add -A is the correct flag to stage all changes including new, modified, and deleted files. There is no widely used git add -a shorthand with the same meaning; mixing up the case is a common source of confusion when someone expects deleted files to be staged and they are not.
Why does --no-verify sometimes get used, and is it safe?
--no-verify skips Git hooks — most commonly pre-commit and commit-msg hooks — allowing a commit to go through even if a hook would normally block it. It is occasionally necessary in genuine emergencies, but reaching for it routinely is usually a sign that the hook itself is misconfigured or too strict, not that the commit is actually exempt from the checks the hook enforces.
Can short flags like -rf be combined, and does the order matter?
POSIX-style short flags can generally be stacked behind a single dash, so rm -rf is equivalent to rm -r -f. Order between the flags themselves usually does not matter, but the flags conventionally come before the positional arguments (rm -rf old/ rather than rm old/ -rf), even though many modern tools tolerate both orders.
Does this reference cover Windows PowerShell flags too?
No — this reference documents POSIX-style short (-x) and long (--xyz) flag conventions as used by git, docker, kubectl, curl, rsync, npm, and most Unix/Linux command-line tools. PowerShell cmdlets use a different convention (-Verb-Noun parameters like -Force or -Recurse) that is not covered here.