re: Bash Brackets Quick Reference VIEW POST


You missed one of the really great BASHisms: <( COMMAND ). Basically, run command in a subshell, then return it's output through a file-descriptor. Meaning that you can do things like:

  • diff two streams
  • run a command within a shell to create an input-"file" for other commands that want input in the form of a file rather than a stream.

Another great one is VAR=($( COMMAND )) ...which takes the output from COMMAND and creates an array-variable from it.

Also useful is $( COMMAND )$? for when you care about how a command exited but not its output (e.g., you want to test to see if grep found a string in a file, [[ $( grep -q PATTERN FILE )$? ]].


the $( COMMAND )$? trick is a very bad one. Please don't advertise it, it basically NEVER works as you intend it to.


Not sure what your experience is, but mine is that it works pretty much exactly as one would reasonably expect. It's functionally equivalent to executing something like:


if [[ $? ]]

But without any shell-linters bitching about using an inefficient execution-form.

That said, you need to be familiar with what the subshelled-command's likely outputs are going to be. Which is to say:

  • If the subshelled-command has an output other than just an exit code, you need to suppress it. Some commands have a built-in "quiet" option; for those that don't, you can suppress by redirecting output to /dev/null. Failing to suppress output will tend to cause evaluation-logic to evaluate as a string of <COMMAND_OUTPUT><COMMAND_EXITCODE> rather than an integer of <COMMAND_EXITCODE>.
  • Similarly, if you care to handle more than a -eq 0 or -ne 0 output, you need to be familiar enough with the given command's possible exit-codes to set up the appropriate handlers you might want/need.

These are great! When I get in front of a keyboard, I’ll add them to the list! Thanks for sharing. What are the most common file-expecting commands you use the sub shell redirect with?


AWS CLI for (particularly for CloudFormation) seems to not quite process STDIN for the --parameters flag as one might expect. Usually have to do something like what I put in my article when I'm doing stack-iterations as part of a quick test-change-test cycle (where "quick" is relative to things like RDS - there's frequently not enough time to wait for one launch to delete before moving on to the next launch).

Thanks again for the tips! I just wanted to let you know that I updated the article with your suggestions. 😀

Some comments have been hidden by the post's author - find out more

code of conduct - report abuse