You can chain multiple commands in a single line using semicolons, double ampersands, or pipes to control execution flow and redirect output. Semicolons run commands sequentially regardless of success, while && stops if an error occurs. Pipes pass the output of one command as input to another, enabling powerful automation workflows directly from your terminal.
Understanding Sequential Execution
The most fundamental way to execute multiple commands on one line is by separating them with a semicolon;. This operator tells the shell to run the first command, wait for it to finish, and then immediately proceed to the next command. The exit status of the previous command does not influence whether the next one runs. This is useful for simple tasks where you want a series of actions to happen in order, such as changing directories and listing files.
For example, the command cd /tmp; ls -la changes your current directory to /tmp and then lists all files in that directory. If the directory change fails because /tmp does not exist, the shell will still attempt to run ls -la, likely resulting in an error message about the wrong working directory. While this might seem inefficient, it provides predictable behavior when you need guaranteed sequential execution without conditional checks.
However, in many automation scenarios, you want to prevent errors from cascading. If a setup step fails, running subsequent steps is often pointless or dangerous. This is where the logical AND operator && becomes essential. When you use cmd1 && cmd2, the shell executes cmd2 only if cmd1 completes successfully (returns an exit code of zero). If cmd1 fails, the shell skips cmd2 entirely and moves to the next part of the chain or exits.
Consider a deployment script snippet: git pull && npm install && npm start. Here, the application only starts if the code has been pulled and dependencies installed successfully. This pattern is critical for robust shell scripting. You can combine these operators to create complex logic. For instance, cmd1 ; cmd2 || cmd3 runs cmd1, then cmd2, but if either fails, cmd3 runs as a fallback. Understanding these distinctions allows you to write safer and more efficient one-liners.
Piping Output Between Commands
While sequential execution handles multiple independent commands, piping allows you to connect the output of one command directly to the input of another. The pipe character| is one of the most powerful features of the Unix philosophy, which encourages small tools that do one thing well. Instead of saving intermediate results to temporary files, you stream data between processes.
A classic example is filtering log entries. Suppose you have a large log file and need to find specific errors. You can use cat /var/log/syslog | grep "error" | sort. The cat command outputs the file content, which is piped into grep to filter lines containing "error". The filtered lines are then piped into sort to arrange them alphabetically. This approach is memory-efficient because data flows through memory buffers rather than being written to disk.
You can also mix redirection with piping. For example, command1 | command2 > output.txt takes the output of command1, passes it to command2, and saves the final result of command2 to a file. This is distinct from redirecting the output of command1 before it reaches command2. Properly understanding where the pipe sits in your command structure is vital for achieving the desired data flow.
When working with network tools, you might fetch data and process it simultaneously. As discussed in our guide on catching filenames with wget and cURL, you can pipe raw download streams into parsers. For instance, wget -qO- http://example.com/data.json | jq '.items' downloads JSON data silently and extracts specific fields using jq without creating a local file first. This technique reduces I/O overhead and speeds up processing pipelines.
Combining Redirection and Chaining
Output redirection operators like> (overwrite) and >> (append) work seamlessly with chained commands. You can redirect the standard output of an entire chain or individual commands within it. For example, cmd1 > log.txt && cmd2 >> log.txt overwrites log.txt with the output of cmd1 and appends the output of cmd2 to the same file. This is useful for logging multi-step processes.
It is important to note that redirection applies to the command immediately preceding it unless grouped. To redirect the output of multiple commands, use curly braces or parentheses to group them. The syntax { cmd1; cmd2; } > output.txt captures the combined stdout of both commands into output.txt. Parentheses ( cmd1; cmd2 ) > output.txt create a subshell, which means variables set inside the group do not persist outside of it. Curly braces run in the current shell environment, so variable changes are preserved.
This distinction matters when debugging or setting variables during a pipeline. If you need to check the exit status of a group of commands, grouping is necessary. Additionally, you can redirect standard error separately using 2>. Combining these allows for sophisticated error handling, such as sending errors to a different log file than standard output.
For scheduled tasks, mastering these one-liners simplifies cron jobs significantly. Instead of writing complex scripts for simple updates, you can place a chained command directly in your crontab. As detailed in our article on Linux scheduled tasks, keeping cron entries concise makes maintenance easier. You can also integrate these techniques into broader automation workflows, such as those involving Docker Compose or OpenVPN, as seen in our guide on shell script automation.
Best Practices for Readability
Although one-liners are powerful, they can become difficult to read if too long. Use line continuation characters backslash\ to break long commands across multiple lines for better readability. For example:
long_command \
--flag1 value1 \
--flag2 value2
This works identically to a single line but is much easier to edit and understand. Always test your chains in a safe environment before deploying them in production scripts. Use set -e at the top of scripts to exit immediately on any error, mimicking the behavior of the && operator for the entire script. Finally, comment your one-liners if they contain complex logic, ensuring that future you or other team members can understand the intent behind the chaining and redirection choices.
Frequently Asked Questions
What is the difference between ; and && in command chaining?
The semicolon ; runs the next command regardless of whether the previous one succeeded or failed. The double ampersand && only runs the next command if the previous one exited with a status code of zero, indicating success. Use ; for independent tasks and && for dependent steps.
How do I save both standard output and standard error to a file?
You can redirect standard error to standard output using 2>&1 and then redirect the combined stream to a file. For example, command > output.log 2>&1 ensures that both normal output and error messages are captured in output.log.
Can I use pipes with background processes?
Yes, you can pipe the output of a background process, but be cautious of blocking. If the background process writes more data than the pipe buffer can hold, it may block until the reader consumes the data. It is often safer to redirect output to a file when using background processes to avoid deadlocks.
Why would I use parentheses instead of curly braces for grouping?
Parentheses create a subshell, meaning any variable changes or environment modifications made inside the group do not affect the parent shell. Curly braces run in the current shell, preserving variable states. Use parentheses when you want isolation and curly braces when you need to modify the current environment.
How can I handle errors in a pipeline gracefully?
By default, a pipeline returns the exit status of the last command. To catch errors from earlier commands, use the pipefail option with set -o pipefail. This causes the pipeline to return the exit status of the last command that failed, allowing you to detect issues anywhere in the chain.