In bash, what does the `$(<file)` form of command substitution do differently from `$(cat file)`, and when would you not use it?

## What the form is `$(< file)` — the redirection-only spelling of command substitution — substitutes the contents of `file`. There is no command inside the parentheses at all, just an input redirection. ```bash version=$(<VERSION) pid=$(</var/run/app.pid) ``` The result is exactly what `$(cat file)` would have produced: the whole file, with **all** trailing newlines stripped, subject to word splitting and globbing if you leave it unquoted. ## The difference: no external process `$(cat file)` is a genuine command substitution around a genuine external command. Bash sets up a subshell and runs `/bin/cat`, which means a `fork` plus an `exec` plus process teardown per invocation. `$(<file)` is recognised by bash as a special case, and bash reads the file itself rather than launching `cat`. The bash manual describes it as the equivalent but faster form for exactly this reason. On a single read the difference is invisible — a fraction of a millisecond. It becomes measurable in the shape where shell scripts usually hurt: a loop. ```bash # thousands of external processes for f in /proc/[0-9]*/comm; do name=$(cat "$f"); done # no external process for the read for f in /proc/[0-9]*/comm; do name=$(<"$f"); done ``` At a few thousand iterations this is the difference between a script that feels instant and one that takes a noticeable pause — the same class of win as replacing `echo "$x" | grep pat` with `[[ $x == *pat* ]]`. ## When not to use it **Portability.** `$(<file)` comes from ksh and is implemented by bash and zsh. It is **not** in POSIX. A script whose shebang is `#!/bin/sh` may be running under dash on Debian or Ubuntu, or busybox ash in an Alpine container, and there it is a surprise rather than a fast read. If the script declares `#!/usr/bin/env bash`, use it freely; if it declares `#!/bin/sh`, write `$(cat file)`. **Anything but a whole plain file.** The form takes a redirection, not a pipeline. As soon as you need the first line only, a decompression, a filter, or a command's output rather than a file's contents, you need a real command again: ```bash first=$(head -n1 file) # cannot be expressed as $(<file) body=$(zcat file.gz) # likewise ``` For "first line only", the shell-native alternative avoids the external process too: ```bash IFS= read -r first < file ``` **Very large files.** Both forms slurp the whole file into a single shell string in memory. `$(<huge.log)` is not more memory-efficient than `$(cat huge.log)` — it is only cheaper in processes. Past a few megabytes, stream it instead of capturing it. **Special files that block.** Reading a FIFO or a character device with either form blocks until the writer closes; the substitution form does not make that safer. ## What is unchanged Everything about the *result* is the same, and forgetting that is the usual mistake: - All trailing newlines are stripped, so a file ending in a blank line loses it. - The result is word-split and glob-expanded unless quoted, so `"$(<file)"` keeps the quotes. - Reading a file that does not exist prints an error to stderr and yields an empty value; the script must handle the empty case rather than assume content. ## The short answer to give "Same result, one fewer process — bash reads the file itself instead of exec'ing `cat`. Use it in bash scripts, especially inside loops; fall back to `$(cat file)` in `#!/bin/sh` scripts and any time you actually need a command rather than a file's raw contents."