A more sophisticated approach might involve defining some
common components, notably the "preamble" that consists
of the SLONIK CLUSTER NAMESLONIK ADMIN CONNINFO
commands that are common to every Slonik script, thus:

The PREAMBLE value could then be reused over and
over again if the shell script invokes slonik
multiple times. You might also consider using SLONIK INCLUDE and place the preamble in a file that is
included.

Shell variables provide a simple way to assign names to sets
and nodes:

That is of somewhat dubious value if you only have 4 tables,
but eliminating errors resulting from enumerating large lists of
configuration by hand will make this pretty valuable for the larger
examples you'll find in "real life."

You can do even more sophisticated things than this if your
scripting language supports things like:

"Record" data structures that allow
assigning things in parallel

Functions, procedures, or subroutines, allowing you
to implement useful functionality once, and then refer to it multiple
times within a script

Some sort of "module import" system so
that common functionality can be shared across many
scripts

If you can depend on having Bash, zsh, or Korn shell available, well,
those are all shells with extensions supporting reasonably
sophisticated data structures and module systems. On Linux, Bash is
fairly ubiquitous; on commercial UNIX™, Korn
shell is fairly ubiquitous; on BSD, "sophisticated"
shells are an option rather than a default.

At that point, it makes sense to start looking at other
scripting languages, of which Perl is the most ubiquitous, being
widely available on Linux, UNIX™, and BSD.