bash adds single quotes to > (redirect) during variable expansion (breaking my redirect)

Question

After research, Im not certain this is possible in a bash script. The most likely reason ive found is due to bash's order of shell expansions. (maybe?)

What i would like to happen, Is the ability to enable/disable redirection (>) of a statement via a prior variable.

for example: the printf output below should be (redirected >) based upon what the variable $SendGrafana contains.
However this example code does not work:

SendGrafana=" > /dev/tcp/192.168.1.242/5062"

awk -v vars="$vars" 'BEGIN{printf "output.api %s \n", vars;}' $SendGrafana

i was hoping the code above would work just like this:

awk -v vars="$vars" 'BEGIN{printf "output.api %s \n", vars;}' > /dev/tcp/192.168.1.242/5062

Additionally- When i run the script with set -x (for debugging), i see that single quotes (') are being wrapped around just the redirect (>) , which i assume is the problem, as nothing gets sent to my netcat listener. I have read that this is only for user readability when using set -x, however the problem remains.

Here is the relevant output with set -x enabled:

+ awk -v vars=3 'BEGIN{printf "output.api %s \n", vars;}' '>' /dev/tcp/192.168.1.242/5062

(note the '>' )

I have tried many methods, both at the variable declaration as well as at the variable expansion, but all fail to redirect the output to 192.168.1.242:5062 when script is called. Thank you

---

EDIT BELOW- (adding this part which was in my comments, as i was trying to keep the question brief, but was suggested it should be here):

To add some more context: the reason im even using this $SendGrafana variable, as opposed to no variable and literally > /dev/tcp/192.168.1.242/5062 after each awk statement- is so i can easily set $SendGrafana= " " , and my script will output to STDOUT (and not send to 192.168.1.242 via > /dev/tcp/192.168.1.242/5062). I need the output on STDOUT ONLY during debugging / test adding new statements.

Answer 1

The problem is indeed order of evaluation.

This just puts the text into the command line: it is too late for shell to implement the redirection.

paul $ j=" > foo.txt "
paul $ echo Words Here $j
Words Here > foo.txt
paul $ ls -l foo.txt
ls: cannot access 'foo.txt': No such file or directory

This causes the shell to re-evaluate the whole command.

paul $ eval echo Words Here $j
paul $ ls -l foo.txt
-rw-r--r-- 1 paul paul 11 Aug 19 22:38 foo.txt
paul $ cat foo.txt
Words Here
paul $ 

The eval built-in can be difficult to use correctly, and I avoid it wherever possible. Your command gets evaluated twice (once as args to eval, and again by eval itself), which can make your quoting difficult and tedious (particularly where awk is involved, where single and double quotes are already needed.) Also, mistakes can cause your variables to be executed as commands, with unintended consequences. More here:

unix.stackexchange.com/questions/278427/why-and-when-should-eval-use-be-avoided-in-shell-scripts

Example added:

One suggestion from the StackExchange link I posted is to have shell make a new file descriptor, and direct that to the target first.

This is a somewhat overdressed test script.

#! /bin/bash

#.. First arg to script is -l for test runs.

#.. For your live action.
Grafana="/dev/tcp/192.168.1.242/5062"

#.. For my demo here.
Grafana="./foo.txt"

rm -f foo.txt

if [[ "${1}" = "-l" ]]; then
    exec 7>&1
    shift 1
else
    exec 7>"${Grafana}"
fi  
 
vars="${@}" #.. Rest of args to output.

awk -v vars="$vars" 'BEGIN{printf "output.api %s \n", vars;}' 1>&7

ls -l foo.txt && cat foo.txt

And a test with logging to terminal, and then to a named file/device.

Paul--) ./Swit -l Easy Living
output.api Easy Living 
ls: cannot access 'foo.txt': No such file or directory
Paul--) ./Swit Easy Living
-rw-r--r-- 1 paul paul 24 Aug 20 09:22 foo.txt
output.api Easy Living 
Paul--) 

You can leave fd 7 open, and use it multiple times in the script. You can close it with exec 7>&-