Subshells and Command Grouping

Bash gives you two ways to treat multiple commands as a unit: ( commands ) runs them in a subshell, a forked child process with its own copy of variables and working directory, while { commands; } runs them in the current shell using braces, sharing and mutating the parent's state directly. Choosing the wrong one is a common source of bugs, such as a cd or variable assignment silently vanishing after the block ends because it happened in a forked child.

Subshells are the right tool when you want temporary isolation, such as changing directories only for a scoped block of work, running commands with modified umask or IFS that shouldn't leak, or grouping a pipeline's output so ( cmd1; cmd2 ) | cmd3 merges the stdout of both cmd1 and cmd2 into a single stream feeding cmd3. Command grouping with braces is preferred when you need the block's side effects, like variable assignments or exit, to actually affect the calling shell, and it also avoids the overhead of forking a new process, which matters in tight loops.

Both ( ) and { } return the exit status of the last command executed inside them, so if ( grep -q pattern file && process_file ); then ... works naturally for combining a guard condition and an action into a single testable unit. With set -e active, an error inside a subshell only terminates that subshell, not the parent, whereas an error inside a brace group under set -e propagates and can terminate the calling shell unless it's the condition of an if or part of &&/||.