DEV Community

Bash Brackets Quick Reference

Ryan Palo on June 20, 2018

Cover image credit: Fonts.com Bash has lots of different kinds of brackets. Like, many much lots. It adds meaning to doubling up different brack...

Read full post

Thomas H Jones II • Jun 20 '18 • Edited

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 )$? ]].

Ryan Palo • Jun 21 '18

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?

Thomas H Jones II • Jun 21 '18 • Edited

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).

Ryan Palo • Jun 21 '18

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

Stanislav Kogan • Dec 27 '19

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

Thomas H Jones II • Dec 30 '19

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:

<COMMAND>

if [[ $? ]]
then
…

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.

Comment hidden by post author - thread only accessible via permalink

Stanislav Kogan • Dec 31 '19 • Edited

You totally misunderstand what [[ $? ]] actually does. It is actually equivalent to [[ -n $? ]], with -n being the operator for non-empty string test. Since $? always contains an exit status of the last command, it will always be a non empty string, so [[ $? ]] will always return 0 and evaluate to true in if context.

Please read up on how if works in bash and stop screwing up noobs with worthless code.

Thomas H Jones II • Dec 31 '19

Ok, so, I shortcut on my prior statement. The response was basically, "here's something you can start your Googling with," not, "here's a whole freaking book on the topic." But, congratulations, rage-boy, in your quest to service "noobs" (great to throw that term out there, btw: really shows your head-space and overall level of respect for your community-members), you've extended this thread beyond the scope of a simple Google-starter. And for all of that belaboring, the point still stands that there's many useful, reliable ways to use the $( command )$? construct. Clearly your opinion differs. Clearly you've been badly snakebitten (or otherwise simply have an axe to grind). However, like with any useful tool or construct, just because there are ways that it can fail within a given context, it's still useful when correctly used in the right contexts.

Ryan Palo • Dec 31 '19

Hi guys! Just FYI, I’ve muted and moderated both of your comments in this particular thread. Let’s try to keep it positive and helpful for the people who need this info next time. I’d appreciate it if you’d take any further posturing/bickering into dms and out of my comments. Thanks!

Stanislav Kogan • Dec 31 '19

You have not demonstrated any useful way of using the $( command )$? construct. Your original one is dangerous and misleading. I'm asking you, please stop screwing over noobs - bash can be very unforgiving and can do a lot of damage when used incorrectly.

Thomas H Jones II • Dec 31 '19

No worries. After my final reply, I did a "who is this guy" click on his profile noticed that he'd apparently created an account just to piss on the thread (created the day he started thread-crapping and only activity shown on profile is the thread-crapping). So, had no further intent to respond.

Stanislav Kogan • Dec 31 '19

Yes, I'm new here, but I'm not new. I write a LOT of bash on my job, so when I see these dangerous "recommendations", it makes me cringe.
And you, my friend, should reign in your prideful graphomania and actually TEST your code before you post it.

Ian Kirker • Jun 21 '18

A couple of things about HEREDOC bits:

HEREDOCs when used with a command are fed into stdin for a command. The way you've used it in your first example for assignment to a variable doesn't work, at least for me and my bash 4.4.19.

$ nice_message=<<MESSAGE
Hi there!  I really like the way you look
when you are teaching newbies things
with empathy and compassion!
You rock!
MESSAGE
$ echo $nice_message

$

$ cat <<MESSAGE
Hi there!  I really like the way you look
when you are teaching newbies things
with empathy and compassion!
You rock!
MESSAGE
Hi there!  I really like the way you look
when you are teaching newbies things
with empathy and compassion!
You rock!
$

If you put single quotes around the initial tag, the HEREDOC will be treated like a single-quoted string, leaving variable expressions uninterpolated.

$ cat <<EOF
$RANDOM
EOF
4578

$ cat <<'EOF'
$RANDOM
EOF
$RANDOM

You can also use triple less-than symbols without a tag to just feed in a single simple string, like so:

$ cat <<EOF
beep
EOF
beep

$ cat <<<beep
beep
$

Ryan Palo • Jun 29 '18

I updated the post with your help and extra info! Thanks again!

Ryan Palo • Jun 21 '18

Hm. I’ll take a look at that. Thanks! I was doing all of my local testing in Zsh, and forgot that there might be differences.

Ben Sinclair • Jun 21 '18

This is a really great overview. Probably the clearest thing I've ever read about substitutions and their ilk :)

One thing I might add to it would be just to flag which bits are POSIX. Like where you have the single- vs. double-square-brackets rule of thumb, you say that if you need to use test or [ you'll know it - well the main reason you'd know it is if you were wanting to write a script which might be portable, i.e. work in a foreign shell.

Ryan Palo • Jun 21 '18

Thanks! I’ll put something in there about that. I tried to avoid it, because I found during my research that articles that constantly focused on POSIX really distracted from the rest of the info. But you are right that it’s probably good to at least mention that it is a thing.

Thanks for the feedback!

Sanket Patel • Jun 28 '18

Small fix for -
echo ${url%%/*}

It actually prints -
https:

Ryan Palo • Jun 29 '18

Ah! You're totally right. Let me get that fixed. Thanks!

John Harrington • Jan 30 '22

Thanks for this valuable article. So many of us use bash scripting without ever properly learning it.

I want to point out that, in a Boolean context, the (( )) is an evaluation of the contained expression, not the exit code of the double parens itself. For example:

 if (( 2 - 2 )) # false (0)
 then
      echo hi
 else
      echo die
 fi

Even though the exit code of (( 2 - 2 )) is 1 (true), this outputs die since the evaluation of the expression 2 - 2 is 0.

Note that (( (( 2 - 2 )) )) would, however, be false, since the evaluation of (( 2 - 2 )) is its exit code.

Ben Halpern • Jun 20 '18

Love this post. Bash has remained something I've been content to stumble around with instead of learning, but this got me intrigued.

Thomas H Jones II • Jun 20 '18 • Edited

Heh... There's so much I can do with BASH that, when under a time-crunch, it's hard for me to justify figuring out "how do I accomplish 'X' in <INSERT_LANGUAGE_OR_DSL>" ...when I can just bang it out in BASH in like two seconds

Ben Halpern • Jun 20 '18

Yeah, I logically know all of this but have still maintained vast ignorance.

Ryan Palo • Jun 21 '18

Basically until I wrote this, I just guessed and then tried another set of brackets when one didn’t work. I do that with a lot of stuff in Bash, so I’m going back to fill in all the gaps.

Joe Cannatti • Feb 20 '19

This is great! I use bash a ton but wasn't aware of several of these. Really useful.

Ryan Palo • Feb 20 '19

Thanks! Glad it was able to help you out!

michaeltd • Jun 21 '18

I once renegotiated my salary when the CTO asked "But how did you passed standard input to the application?". Got a 30%. lolz ;..;

Andrew (he/him) • Mar 23 '19

Great article! Thanks for writing it!

Ryan Palo • Mar 23 '19

Thanks! Glad you liked it!

Stanislav Kogan • Dec 27 '19

It's nice to show off some tricks, but the amount of bad and downright DANGEROUS practices in this article is just too much. Really, sometimes it's just best to READ THE F-CKING MAN PAGE!!!

Ryan Palo • Dec 27 '19

Hi there! I found the man pages dense and opaque at times, which is why I put this article together. Are there any especially dangerous practices that you’d like to point out?

Stanislav Kogan • Dec 27 '19

It's true that bash man page is a very dry reading, but once you get the basics figured out, it is definitely the best source. That's why it's important to use the correct terminology in your article - it will allow people to quickly find the necessary subjects in the man page.

Now, for the mistakes in the article.

"(( Double Parentheses ))" is actually a compound command that undergoes arithmetic evaluation. its the equivalent of "let".

# Not correct
a=(( 4 + 1 ))

# Correct
((a=4 + 1))

"$( Dollar Single Parentheses )" is actually called "Command substition"
"$( Dollar Single Parentheses Dollar Q )$?" is an absoultely HORRIBLE trick, NEVER EVER EVER do this! Oh, and btw, this doesn't actually work, because, the few times that it won't spew out an error, it will always evaluate to true.

# This is very bad
if [[ $( grep -q PATTERN FILE )$? ]]; then
 ...

# Do this instead
if grep -q PATTERN FILE; then
 ...

# oh, and by the way
[[ $(false)$? ]]; echo $?
#=> 0
# thats because  $? is evaluated as a string, and "1" is non empty

[[ $(false) $? ]]; echo $?
#=> bash: conditional binary operator expected
#=> bash: syntax error near `$?'
# LOL

"$(( Dollar Double Parentheses ))" is actually called "Arithmetic expansion" with the expression within undergoing "Arithmetic evaluation". An interesting fact: double paratheses is not the only place arithmetic evaluation occurs: it also occurs inside array subscripts, which can be a pretty surprising thing sometimes.
[ Single Square Brackets ]. This deserves a special caution: unless you require backward compatibility with classic sh, you should NEVER use it. It's error-prone, requires gillion of quotes to make reliable and spawns a separate process for no good reason. Also, "[[" has more features.
"{ Single Curly Braces }" is called "brace expansion".
"${dollar braces}" is called "parameter expansion".

Ryan Palo • Dec 27 '19

Yep, I’m aware of what these are all called. I wrote it this way because the target audience most likely wouldn’t, and I wanted to make it an accessible visual guide. That being said, your other notes are helpful, and, when I get a chance, I’ll do my best to add the warnings and caveats where they’re needed. Thanks for taking the time to walk me through your experiences!

Chad Woolley • Jun 21 '18 • Edited

Great summary.

I've written a ton of bash.

My rule for writing bash is to write as little bash as possible.

Anything with any sort of even mildly complex logic, use a modern scripting language - Ruby (my preference) or Python.

I've also written github.com/thewoolleyman/process_h... which makes dealing with subprocesses much nicer in Ruby.

Stanislav Kogan • Dec 27 '19 • Edited

My experience has been the exact opposite. Bash, when properly learned, is very powerful and, what's more important, SELF SUFFICIENT.
Ruby and Python either make for very long scripts to accomplish even the basic tasks or pull in a gillion libraries as dependencies, which turns it into a sysadmin nightmare. BTW, the process helper library you linked to is a classic example of that.

My personal preferences for scripting: bash when possible, Perl when necessary, Python if you're adventurous and NEVER Ruby.

Venkatesh-Prasad Ranganath • Jun 25 '18

A useful list. Thanks for writing this up :)

Aaron Roydhouse • Jun 21 '18

There is also triple < here doc that provides a string as stdin input, e.g.
cat <<<"this string"

Ryan Palo • Jun 21 '18

Cool! Does this give you any benefits over “echo some string | cat”? I guess it saves cat from being run in a sub shell, maybe?

MatthiasvB • Jan 15 '21

I think you made a mistake just under "Using a default value if the variable isn't defined.". Check the "," after "Hello"
Otherwise really great stuff! Thanks!

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