Shell - what does <<-'EOF' mean [duplicate] - bash
I needed to write a script to enter multi-line input to a program (psql).
After a bit of googling, I found the following syntax works:
cat << EOF | psql ---params
BEGIN;
`pg_dump ----something`
update table .... statement ...;
END;
EOF
This correctly constructs the multi-line string (from BEGIN; to END;, inclusive) and pipes it as an input to psql.
But I have no idea how/why it works, can some one please explain?
I'm referring mainly to cat << EOF, I know > outputs to a file, >> appends to a file, < reads input from file.
What does << exactly do?
And is there a man page for it?
The cat <<EOF syntax is very useful when working with multi-line text in Bash, eg. when assigning multi-line string to a shell variable, file or a pipe.
Examples of cat <<EOF syntax usage in Bash:
1. Assign multi-line string to a shell variable
$ sql=$(cat <<EOF
SELECT foo, bar FROM db
WHERE foo='baz'
EOF
)
The $sql variable now holds the new-line characters too. You can verify with echo -e "$sql".
2. Pass multi-line string to a file in Bash
$ cat <<EOF > print.sh
#!/bin/bash
echo \$PWD
echo $PWD
EOF
The print.sh file now contains:
#!/bin/bash
echo $PWD
echo /home/user
3. Pass multi-line string to a pipe in Bash
$ cat <<EOF | grep 'b' | tee b.txt
foo
bar
baz
EOF
The b.txt file contains bar and baz lines. The same output is printed to stdout.
This is called heredoc format to provide a string into stdin. See https://en.wikipedia.org/wiki/Here_document#Unix_shells for more details.
From man bash:
Here Documents
This type of redirection instructs the shell to read input from
the current source until a line
containing only word (with no trailing
blanks) is seen.
All of the lines read up to that point are then used as the
standard input for a command.
The format of here-documents is:
<<[-]word
here-document
delimiter
No parameter expansion, command substitution, arithmetic expansion, or
pathname expansion is performed on
word. If any characters in word are
quoted, the
delimiter is the result of quote removal on word, and the lines
in the here-document are not expanded.
If word is unquoted, all lines of the
here-document are subjected to parameter expansion, command
substitution, and arithmetic
expansion. In the latter case, the
character sequence \<newline> is
ignored, and \ must be used to quote the characters \, $, and `.
If the redirection operator is <<-, then all leading tab characters
are stripped from input lines and the
line containing delimiter. This
allows here-documents within shell scripts to be indented in a natural fashion.
In your case, "EOF" is known as a "Here Tag". Basically <<Here tells the shell that you are going to enter a multiline string until the "tag" Here. You can name this tag as you want, it's often EOF or STOP.
Some rules about the Here tags:
The tag can be any string, uppercase or lowercase, though most people use uppercase by convention.
The tag will not be considered as a Here tag if there are other words in that line. In this case, it will merely be considered part of the string. The tag should be by itself on a separate line, to be considered a tag.
The tag should have no leading or trailing spaces in that line to be considered a tag. Otherwise it will be considered as part of the string.
example:
$ cat >> test <<HERE
> Hello world HERE <-- Not by itself on a separate line -> not considered end of string
> This is a test
> HERE <-- Leading space, so not considered end of string
> and a new line
> HERE <-- Now we have the end of the string
POSIX 7
kennytm quoted man bash, but most of that is also POSIX 7: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04 :
The redirection operators "<<" and "<<-" both allow redirection of lines contained in a shell input file, known as a "here-document", to the input of a command.
The here-document shall be treated as a single word that begins after the next <newline> and continues until there is a line containing only the delimiter and a <newline>, with no <blank> characters in between. Then the next here-document starts, if there is one. The format is as follows:
[n]<<word
here-document
delimiter
where the optional n represents the file descriptor number. If the number is omitted, the here-document refers to standard input (file descriptor 0).
If any character in word is quoted, the delimiter shall be formed by performing quote removal on word, and the here-document lines shall not be expanded. Otherwise, the delimiter shall be the word itself.
If no characters in word are quoted, all lines of the here-document shall be expanded for parameter expansion, command substitution, and arithmetic expansion. In this case, the <backslash> in the input behaves as the <backslash> inside double-quotes (see Double-Quotes). However, the double-quote character ( '"' ) shall not be treated specially within a here-document, except when the double-quote appears within "$()", "``", or "${}".
If the redirection symbol is "<<-", all leading <tab> characters shall be stripped from input lines and the line containing the trailing delimiter. If more than one "<<" or "<<-" operator is specified on a line, the here-document associated with the first operator shall be supplied first by the application and shall be read first by the shell.
When a here-document is read from a terminal device and the shell is interactive, it shall write the contents of the variable PS2, processed as described in Shell Variables, to standard error before reading each line of input until the delimiter has been recognized.
Examples
Some examples not yet given.
Quotes prevent parameter expansion
Without quotes:
a=0
cat <<EOF
$a
EOF
Output:
0
With quotes:
a=0
cat <<'EOF'
$a
EOF
or (ugly but valid):
a=0
cat <<E"O"F
$a
EOF
Outputs:
$a
Hyphen removes leading tabs
Without hyphen:
cat <<EOF
<tab>a
EOF
where <tab> is a literal tab, and can be inserted with Ctrl + V <tab>
Output:
<tab>a
With hyphen:
cat <<-EOF
<tab>a
<tab>EOF
Output:
a
This exists of course so that you can indent your cat like the surrounding code, which is easier to read and maintain. E.g.:
if true; then
cat <<-EOF
a
EOF
fi
Unfortunately, this does not work for space characters: POSIX favored tab indentation here. Yikes.
Using tee instead of cat
Not exactly as an answer to the original question, but I wanted to share this anyway: I had the need to create a config file in a directory that required root rights.
The following does not work for that case:
$ sudo cat <<EOF >/etc/somedir/foo.conf
# my config file
foo=bar
EOF
because the redirection is handled outside of the sudo context.
I ended up using this instead:
$ sudo tee <<EOF /etc/somedir/foo.conf >/dev/null
# my config file
foo=bar
EOF
<< EoF basically means:
<< - "read the multi-line input that begins from the next line onward, and treat it as if it's code in a separate file"
EoF - "stop reading immediately after the word EoF is found in the multi-line input"
As other answers have explained, the multi-line input is called a Here Document
A Here Document is often used to generate output to be passed to a subsequent process. For example cat << EoF can be used to generate a desired output, using a Here Document.
Here's an example of using a Here Document to create a text document on the fly:
cat << EoF > ./my-document.txt
Hello world
Have a nice day
EoF
A little extension to the above answers. The trailing > directs the input into the file, overwriting existing content. However, one particularly convenient use is the double arrow >> that appends, adding your new content to the end of the file, as in:
cat <<EOF >> /etc/fstab
data_server:/var/sharedServer/authority/cert /var/sharedFolder/sometin/authority/cert nfs
data_server:/var/sharedServer/cert /var/sharedFolder/sometin/vsdc/cert nfs
EOF
This extends your fstab without you having to worry about accidentally modifying any of its contents.
note to mention that cat << \EOT (see the backslash) will not expand any variables inside, while cat << EOT will do.
examples:
FOO="bar"
cat << \EOT > foobar.txt
echo "$FOO"
EOT
will output:
echo $FOO
while:
FOO="bar"
cat << EOT > foobar.txt
echo "$FOO"
EOT
will output:
echo "bar"
Example to create a json file:
cat << EoF > ./allaccess.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::*"
]
}
]
}
EoF
As a result:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::*"
]
}
]
}
Long story short, EOF marker(but a different literal can be used as well) is a heredoc format that allows you to provide your input as multiline.
A lot of confusion comes from how cat actually works it seems.
You can use cat with >> or > as follows:
$ cat >> temp.txt
line 1
line 2
While cat can be used this way when writing manually into console, it's not convenient if I want to provide the input in a more declarative way so that it can be reused by tools and also to keep indentations, whitespaces, etc.
Heredoc allows to define your entire input as if you are not working with stdin but typing in a separate text editor. This is what Wikipedia article means by:
it is a section of a source code file that is treated as if it were a
separate file.
This isn't necessarily an answer to the original question, but a sharing of some results from my own testing. This:
<<test > print.sh
#!/bin/bash
echo \$PWD
echo $PWD
test
will produce the same file as:
cat <<test > print.sh
#!/bin/bash
echo \$PWD
echo $PWD
test
So, I don't see the point of using the cat command.
Worth noting that here docs work in bash loops too.
This example shows how-to get the column list of table:
export postgres_db_name='my_db'
export table_name='my_table_name'
# start copy
while read -r c; do test -z "$c" || echo $table_name.$c , ; done < <(cat << EOF | psql -t -q -d $postgres_db_name -v table_name="${table_name:-}"
SELECT column_name
FROM information_schema.columns
WHERE 1=1
AND table_schema = 'public'
AND table_name =:'table_name' ;
EOF
)
# stop copy , now paste straight into the bash shell ...
output:
my_table_name.guid ,
my_table_name.id ,
my_table_name.level ,
my_table_name.seq ,
or even without the new line
while read -r c; do test -z "$c" || echo $table_name.$c , | perl -ne
's/\n//gm;print' ; done < <(cat << EOF | psql -t -q -d $postgres_db_name -v table_name="${table_name:-}"
SELECT column_name
FROM information_schema.columns
WHERE 1=1
AND table_schema = 'public'
AND table_name =:'table_name' ;
EOF
)
# output: daily_issues.guid ,daily_issues.id ,daily_issues.level ,daily_issues.seq ,daily_issues.prio ,daily_issues.weight ,daily_issues.status ,daily_issues.category ,daily_issues.name ,daily_issues.description ,daily_issues.type ,daily_issues.owner
Related
Bash next line (\) in command causing spacing issues
I have the following function I want to call: function print_something { echo "test\ something\ yep" } when called it prints: 'test something yep' I would like it to print: 'testsomethingyep' I can get this to print if I do: function print_something { echo "test\ something\ yep" } but I don't think that looks great.. (Root problem is a curl command not an echo)
Consider assembling your pieces an array, and then combining them into a string later. Array definition syntax is far more forgiving -- not requiring backslashes at all, and also allowing comments on each line and between lines. #!/usr/bin/env bash # ^^^^- arrays and printf -v require bash, not sh pieces=( test # this also lets you use comments something # and you don't need any backslashes at all! # one can also have a full-line comment midway through your array "space here" # plus if you want to add a literal space you can do it ) printf -v oneword '%s' "${pieces[#]}" echo "$oneword" ...properly emits: testsomethingspace here
Here are three ideas: #!/bin/bash print_something() { tr -d \\n <<- EOF test something yep EOF echo } print_something2() { echo "test"$(: )"something"$(: )"yep" } print_something3() { tr -d \\t <<- EOF test\ something\ yep EOF } print_something print_something2 print_something3 The first uses a <<- style heredoc to remove all of the leading indentation (that indentation must be hard-tabs for this to work, and coding styles that mandate the use of spaces for indentation render this solution unusable (this is one reason coding styles that mandate the use of spaces in shell scripts are IMO utterly useless)) and the extra tr to remove the newlines. (The additional echo is then needed to add the trailing newline.). The second uses the $(:) command substitution to discard all the intervening whitespace. The 3rd manually deletes all the hard tabs.
Bash - how to add newlines to string in loop with command substitution?
I have a for loop thats iterating over a list of items, gathering statistics. The constructed string is then being sent as the body of an email using the mail command. My question is: what is the proper way to output newlines, as opposed to escaped \n characters as my script is currently doing? Here's the relavent bash code: for x in $([..]); do BODY="${BODY}\nReport for ${x}: \nSuccess: `get_logs $x 1`\nAttempts: `get_logs $x`" done;
As I said in the comments, you can use: echo -e The -e flag enables the interpretation of backslash escapes
You can use newlines inside quoted strings, the only downside of this is that you cannot indent the new lines, because the indent will be part of the string. for x in $([..]); do BODY="${BODY} Report for ${x}: Success: $(get_logs $x 1) Attempts: $(get_logs $x)" done; Alternatively, append each line separately to make your code more readable. for x in $([..]); do BODY+="Report for ${x}:"$'\n' BODY+="Success: $(get_logs $x 1)"$'\n' BODY+="Attempts: $(get_logs $x)"$'\n' done; $'\n' is an ANSI C string and will be replaced by a line feed.
Why does Bash always add a newline when expanding here strings?
Having read the following description of this feature of Bash (excerpt from the man page): Here Strings A variant of here documents, the format is: <<<word The word is expanded and supplied to the command on its standard input. I expected that the interpretation of here strings is that Bash simply passes the contents of a variable directly on a command's standard input, unmodified. Following this logic, the lines [1] and [2] below would be effectively equivalent. [1]~$ printf foo | cat - <(echo end) fooend [2]~$ cat - <(echo end) <<<foo foo end However, Bash added a newline when “expanding” a string, something I didn't anticipate. This happens even when a variable ends with newline itself: [3]~$ printf "foo\n" | cat - <(echo end) foo end [4]~$ cat - <(echo end) <<<foo$'\n' foo end Tested in 4.2.25 and 4.3.30. So my question is: is this behavior specified anywhere in Bash docs? Can I depend on it in scripts?
Not definitive, but I believe a here string is intended to be equivalent to a single-line here document, so that cat <<< foo and cat <<EOF foo EOF are equivalent. Since a here document always ends with a newline, so should the here string. Consider this simple use case for a here string: IFS=: read foo bar <<< "a:b" # foo=a # bar=b If a newline weren't provided by the here string, the exit status of read would be 1. (See with printf "foo" | { read; echo $?; } vs printf "foo\n" | { read; echo $?; }.)
So my question is: is this behavior specified anywhere in Bash docs? Can I depend on it in scripts? The specification has now been added to the Bash Reference Manual: The result is supplied as a single string, with a newline appended, to the command on its standard input (or file descriptor n if n is specified).
Line error in shell script
I have the following code in a shell script. This only seems to work when it is not defined in a function. The problematic line is the one containing the "<<". The error message is "./run: line 210: syntax error: unexpected end of file" How can I write this correctly within a function? init_database() { cd ../cfg db.sh << ENDC $DB_ADMIN 0 y n ENDC check_status sqlplus $DB_SCHEMA#$DB_NAME < initial_data.sql cd - }
There are a number of ways to fix that problem. 1/ Unindent the here document end marker, such as: cat <<EOF hello $PWD EOF but that will make your code look ugly. 2/ "Indent" the here document begin marker: cat <<' EOF' hello $PWD EOF where that bit before the first EOF is exactly the same as the before the second (tab, four spaces, two tabs, whatever). This allows you to keep your nice indenting, although it doesn't expand variables inside the here-document ($PWD doesn't change). 3/ Allow tabs to be stripped from the start of input lines and the end marker. cat <<-EOF hello $PWD EOF but there's no way to get tabs into the beginnings of lines. 4/ For your purposes, you can also use: ( echo "$DB_ADMIN"; echo "" ; echo "0" ; echo "y" ; echo "n" ) | db.sh check_status sqlplus $DB_SCHEMA#$DB_NAME < initial_data.sql cd - I believe number 4 is the best option for you. It allows nice lining up of the input, tabs and spaces anywhere in the lines and variable expansion.
The end of your "Here document" needs to be unindented, I'm afraid.
The ENDC label must be alone in a line without leading/trailing whitspaces.
How to replace ${} placeholders in a text file?
I want to pipe the output of a "template" file into MySQL, the file having variables like ${dbName} interspersed. What is the command line utility to replace these instances and dump the output to standard output? The input file is considered to be safe, but faulty substitution definitions could exist. Performing the replacement should avoid performing unintended code execution.
Update Here is a solution from yottatsa on a similar question that only does replacement for variables like $VAR or ${VAR}, and is a brief one-liner i=32 word=foo envsubst < template.txt Of course if i and word are in your environment, then it is just envsubst < template.txt On my Mac it looks like it was installed as part of gettext and from MacGPG2 Old Answer Here is an improvement to the solution from mogsie on a similar question, my solution does not require you to escale double quotes, mogsie's does, but his is a one liner! eval "cat <<EOF $(<template.txt) EOF " 2> /dev/null The power on these two solutions is that you only get a few types of shell expansions that don't occur normally $((...)), `...`, and $(...), though backslash is an escape character here, but you don't have to worry that the parsing has a bug, and it does multiple lines just fine.
Sed! Given template.txt: The number is ${i} The word is ${word} we just have to say: sed -e "s/\${i}/1/" -e "s/\${word}/dog/" template.txt Thanks to Jonathan Leffler for the tip to pass multiple -e arguments to the same sed invocation.
Use /bin/sh. Create a small shell script that sets the variables, and then parse the template using the shell itself. Like so (edit to handle newlines correctly): File template.txt: the number is ${i} the word is ${word} File script.sh: #!/bin/sh #Set variables i=1 word="dog" #Read in template one line at the time, and replace variables (more #natural (and efficient) way, thanks to Jonathan Leffler). while read line do eval echo "$line" done < "./template.txt" Output: #sh script.sh the number is 1 the word is dog
I was thinking about this again, given the recent interest, and I think that the tool that I was originally thinking of was m4, the macro processor for autotools. So instead of the variable I originally specified, you'd use: $echo 'I am a DBNAME' | m4 -DDBNAME="database name"
Create rendertemplate.sh: #!/usr/bin/env bash eval "echo \"$(cat $1)\"" And template.tmpl: Hello, ${WORLD} Goodbye, ${CHEESE} Render the template: $ export WORLD=Foo $ CHEESE=Bar ./rendertemplate.sh template.tmpl Hello, Foo Goodbye, Bar
template.txt Variable 1 value: ${var1} Variable 2 value: ${var2} data.sh #!/usr/bin/env bash declare var1="value 1" declare var2="value 2" parser.sh #!/usr/bin/env bash # args declare file_data=$1 declare file_input=$2 declare file_output=$3 source $file_data eval "echo \"$(< $file_input)\"" > $file_output ./parser.sh data.sh template.txt parsed_file.txt parsed_file.txt Variable 1 value: value 1 Variable 2 value: value 2
Here's a robust Bash function that - despite using eval - should be safe to use. All ${varName} variable references in the input text are expanded based on the calling shell's variables. Nothing else is expanded: neither variable references whose names are not enclosed in {...} (such as $varName), nor command substitutions ($(...) and legacy syntax `...`), nor arithmetic substitutions ($((...)) and legacy syntax $[...]). To treat a $ as a literal, \-escape it; e.g.:\${HOME} Note that input is only accepted via stdin. Example: $ expandVarsStrict <<<'$HOME is "${HOME}"; `date` and \$(ls)' # only ${HOME} is expanded $HOME is "/Users/jdoe"; `date` and $(ls) Function source code: expandVarsStrict(){ local line lineEscaped while IFS= read -r line || [[ -n $line ]]; do # the `||` clause ensures that the last line is read even if it doesn't end with \n # Escape ALL chars. that could trigger an expansion.. IFS= read -r -d '' lineEscaped < <(printf %s "$line" | tr '`([$' '\1\2\3\4') # ... then selectively reenable ${ references lineEscaped=${lineEscaped//$'\4'{/\${} # Finally, escape embedded double quotes to preserve them. lineEscaped=${lineEscaped//\"/\\\"} eval "printf '%s\n' \"$lineEscaped\"" | tr '\1\2\3\4' '`([$' done } The function assumes that no 0x1, 0x2, 0x3, and 0x4 control characters are present in the input, because those chars. are used internally - since the function processes text, that should be a safe assumption.
here's my solution with perl based on former answer, replaces environment variables: perl -p -e 's/\$\{(\w+)\}/(exists $ENV{$1}?$ENV{$1}:"missing variable $1")/eg' < infile > outfile
I would suggest using something like Sigil: https://github.com/gliderlabs/sigil It is compiled to a single binary, so it's extremely easy to install on systems. Then you can do a simple one-liner like the following: cat my-file.conf.template | sigil -p $(env) > my-file.conf This is much safer than eval and easier then using regex or sed
Here is a way to get the shell to do the substitution for you, as if the contents of the file were instead typed between double quotes. Using the example of template.txt with contents: The number is ${i} The word is ${word} The following line will cause the shell to interpolate the contents of template.txt and write the result to standard out. i='1' word='dog' sh -c 'echo "'"$(cat template.txt)"'"' Explanation: i and word are passed as environment variables scopped to the execution of sh. sh executes the contents of the string it is passed. Strings written next to one another become one string, that string is: 'echo "' + "$(cat template.txt)" + '"' Since the substitution is between ", "$(cat template.txt)" becomes the output of cat template.txt. So the command executed by sh -c becomes: echo "The number is ${i}\nThe word is ${word}", where i and word are the specified environment variables.
If you are open to using Perl, that would be my suggestion. Although there are probably some sed and/or AWK experts that probably know how to do this much easier. If you have a more complex mapping with more than just dbName for your replacements you could extend this pretty easily, but you might just as well put it into a standard Perl script at that point. perl -p -e 's/\$\{dbName\}/testdb/s' yourfile | mysql A short Perl script to do something slightly more complicated (handle multiple keys): #!/usr/bin/env perl my %replace = ( 'dbName' => 'testdb', 'somethingElse' => 'fooBar' ); undef $/; my $buf = <STDIN>; $buf =~ s/\$\{$_\}/$replace{$_}/g for keys %replace; print $buf; If you name the above script as replace-script, it could then be used as follows: replace-script < yourfile | mysql
file.tpl: The following bash function should only replace ${var1} syntax and ignore other shell special chars such as `backticks` or $var2 or "double quotes". If I have missed anything - let me know. script.sh: template(){ # usage: template file.tpl while read -r line ; do line=${line//\"/\\\"} line=${line//\`/\\\`} line=${line//\$/\\\$} line=${line//\\\${/\${} eval "echo \"$line\""; done < ${1} } var1="*replaced*" var2="*not replaced*" template file.tpl > result.txt
I found this thread while wondering the same thing. It inspired me to this (careful with the backticks) $ echo $MYTEST pass! $ cat FILE hello $MYTEST world $ eval echo `cat FILE` hello pass! world
Lots of choices here, but figured I'd toss mine on the heap. It is perl based, only targets variables of the form ${...}, takes the file to process as an argument and outputs the converted file on stdout: use Env; Env::import(); while(<>) { $_ =~ s/(\${\w+})/$1/eeg; $text .= $_; } print "$text"; Of course I'm not really a perl person, so there could easily be a fatal flaw (works for me though).
It can be done in bash itself if you have control of the configuration file format. You just need to source (".") the configuration file rather than subshell it. That ensures the variables are created in the context of the current shell (and continue to exist) rather than the subshell (where the variable disappear when the subshell exits). $ cat config.data export parm_jdbc=jdbc:db2://box7.co.uk:5000/INSTA export parm_user=pax export parm_pwd=never_you_mind $ cat go.bash . config.data echo "JDBC string is " $parm_jdbc echo "Username is " $parm_user echo "Password is " $parm_pwd $ bash go.bash JDBC string is jdbc:db2://box7.co.uk:5000/INSTA Username is pax Password is never_you_mind If your config file cannot be a shell script, you can just 'compile' it before executing thus (the compilation depends on your input format). $ cat config.data parm_jdbc=jdbc:db2://box7.co.uk:5000/INSTA # JDBC URL parm_user=pax # user name parm_pwd=never_you_mind # password $ cat go.bash cat config.data | sed 's/#.*$//' | sed 's/[ \t]*$//' | sed 's/^[ \t]*//' | grep -v '^$' | sed 's/^/export ' >config.data-compiled . config.data-compiled echo "JDBC string is " $parm_jdbc echo "Username is " $parm_user echo "Password is " $parm_pwd $ bash go.bash JDBC string is jdbc:db2://box7.co.uk:5000/INSTA Username is pax Password is never_you_mind In your specific case, you could use something like: $ cat config.data export p_p1=val1 export p_p2=val2 $ cat go.bash . ./config.data echo "select * from dbtable where p1 = '$p_p1' and p2 like '$p_p2%' order by p1" $ bash go.bash select * from dbtable where p1 = 'val1' and p2 like 'val2%' order by p1 Then pipe the output of go.bash into MySQL and voila, hopefully you won't destroy your database :-).
In place perl editing of potentially multiple files, with backups. perl -e 's/\$\{([^}]+)\}/defined $ENV{$1} ? $ENV{$1} : ""/eg' \ -i.orig \ -p config/test/*
I created a shell templating script named shtpl. My shtpl uses a jinja-like syntax which, now that I use ansible a lot, I'm pretty familiar with: $ cat /tmp/test {{ aux=4 }} {{ myarray=( a b c d ) }} {{ A_RANDOM=$RANDOM }} $A_RANDOM {% if $(( $A_RANDOM%2 )) == 0 %} $A_RANDOM is even {% else %} $A_RANDOM is odd {% endif %} {% if $(( $A_RANDOM%2 )) == 0 %} {% for n in 1 2 3 $aux %} \$myarray[$((n-1))]: ${myarray[$((n-1))]} /etc/passwd field #$n: $(grep $USER /etc/passwd | cut -d: -f$n) {% endfor %} {% else %} {% for n in {1..4} %} \$myarray[$((n-1))]: ${myarray[$((n-1))]} /etc/group field #$n: $(grep ^$USER /etc/group | cut -d: -f$n) {% endfor %} {% endif %} $ ./shtpl < /tmp/test 6535 6535 is odd $myarray[0]: a /etc/group field #1: myusername $myarray[1]: b /etc/group field #2: x $myarray[2]: c /etc/group field #3: 1001 $myarray[3]: d /etc/group field #4: More info on my github
To me this is the easiest and most powerful solution, you can even include other templates using the same command eval echo "$(<template.txt): Example with nested template create the template files, the variables are in regular bash syntax ${VARIABLE_NAME} or $VARIABLE_NAME you have to escape special characters with \ in your templates otherwhise they will be interpreted by eval. template.txt Hello ${name}! eval echo $(<nested-template.txt) nested-template.txt Nice to have you here ${name} :\) create source file template.source declare name=royman parse the template source template.source && eval echo "$(<template.txt)" the output Hello royman! Nice to have you here royman :)
envsubst please don't use anything else (ie. don't eval)