Shell – Why enclose a shell script in curly braces

shellshell-script

What is the reason behind enclosing all lines in a shell script in curly braces?

e.g. the entire content of this script is enclosed in braces:

#!/bin/sh

{
set -e

LATEST="v0.3.5"
DGOSS_VER=$GOSS_VER

if [ -z "$GOSS_VER" ]; then
    GOSS_VER=${GOSS_VER:-$LATEST}
    DGOSS_VER='master'
fi
GOSS_DST=${GOSS_DST:-/usr/local/bin}
INSTALL_LOC="${GOSS_DST%/}/goss"
DGOSS_INSTALL_LOC="${GOSS_DST%/}/dgoss"
touch "$INSTALL_LOC" || { echo "ERROR: Cannot write to $GOSS_DST set GOSS_DST elsewhere or use sudo"; exit 1; }

arch=""
if [ "$(uname -m)" = "x86_64" ]; then
    arch="amd64"
else
    arch="386"
fi

url="https://github.com/aelsabbahy/goss/releases/download/$GOSS_VER/goss-linux-$arch"

echo "Downloading $url"
curl -L "$url" -o "$INSTALL_LOC"
chmod +rx "$INSTALL_LOC"
echo "Goss $GOSS_VER has been installed to $INSTALL_LOC"
echo "goss --version"
"$INSTALL_LOC" --version

dgoss_url="https://raw.githubusercontent.com/aelsabbahy/goss/$DGOSS_VER/extras/dgoss/dgoss"
echo "Downloading $dgoss_url"
curl -L "$dgoss_url" -o "$DGOSS_INSTALL_LOC"
chmod +rx "$DGOSS_INSTALL_LOC"
echo "dgoss $DGOSS_VER has been installed to $DGOSS_INSTALL_LOC"
}

Shellcheck.net deems the script valid with or without the curly braces.

Best Answer

There is no obvious reason to do this. The curly braces is a grouping construct and the commands within them will be executed in the same environment as the rest of the script.

Had it been an ordinary parenthesis, then it would have been a sub-shell (a separate environment from the rest of the script), but in this instance that too would not have made much difference.

One possible reason for this is that it would enable the author to redirect all output from any command within the { ... } to some specific place, as in

{ ...some commands...; } >somefile

but this is obviously not done here.

With parenthesis,

( ...some commands... )

the author would have been able to set shell options and create local variables that don't affect the rest of the script.

Related Solutions

Shell – Using curly brackets (braces) to create folder structure with `mkdir -p`

Maybe this is what you are looking for?

 mkdir -p work/{F1/{temp1,temp2},F2,F3}

Bash – Avoid output buffering for a command group (curly braces) in bash script

(Note to future readers: the tone of exasperation here is not for the question, but for the mistakes I made trying to answer it and the multiple edits they entailed.)

Oh, for pity's sake. The problem is in tail -f. This works just fine:

#!/bin/bash
printf 'hi\n'
{
    for i in 1 2 3 4; do
        sleep 0.5
        /bin/echo $i
    done;
} | cat
printf 'bye\n'

It's not the pipe, it's not the group. It's tail. As in, chasing our own tails!

So, tail -f failed because it doesn't output right away for some reason. Not sure why python -u is failing, but I don't think it's anything in the script. Maybe try unbuffer with it. Try your script with cat, at least, and verify that it's unbuffered in that case.

Earlier failed attempt intentionally left here so future readers can make sense of the comments.

This script exhibits the same kind of buffering problem you're getting:

#!/bin/bash
printf 'hi\n'
{
    for i in 1 2 3 4; do
    sleep 0.5
    printf '%s\n' $i
    done;
} | tail -f
printf 'bye\n'

This one does not. Output inside the group is redirected to stderr, then stderr from the whole group is piped to the command. Since it's stderr, it's unbuffered.

#!/bin/bash
printf 'hi\n'
{
    for i in 1 2 3 4; do
    sleep 0.5
    printf '%s\n' $i 1>&2
    done;
} |& tail -f
printf 'bye\n'

Adapted from Wang HongQin's answer in this question. The difficulty was in finding a way to unbuffer the pipe with braces rather than an explicit command. Had to fiddle around a while to get the redirection working properly.

Best Answer

Related Solutions

Shell – Using curly brackets (braces) to create folder structure with `mkdir -p`

Bash – Avoid output buffering for a command group (curly braces) in bash script

Related Question