Simpler indirect expansion

Hi,

have these variables set like this:

firewall_ports_tcp_mythtv="3306 6543 6544"
prefix=firewall_ports
application=mythtv

I can get tcp ports for that application like this:

tmp="${prefix}_tcp_${application}" # optional brackets around application
tcp_ports="${!tmp}" # indirect expansion with exclamation mark

If there a way to do that without using tmp variable?

-Paavo

Should have been using the search better *before* posting...

tcp_ports="$(eval echo "\$${prefix}_tcp_${application}")"

Sorry for wasting bandwidth, but here it is also for others looking for the same (or similar) thing.

I found severe warnings about eval ("evil") security, is the above line particularly dangerous?

-Paavo

Originally Posted by Paavo I found severe warnings about eval ("evil") security, is the above line particularly dangerous?

var="hello; ls"
echo "$var"
eval echo "$var"

Just be careful where your input comes from. You should really only use this if you have a lot of control over the contents of the variable. I'm sure a lot of the concern is about a user typing mynanme; rm -rf * into some unfortunate login prompt, but really, who's going to put eval in something like that? It's more so one can feel comfortable with something like this:

var="`cat myscript.sh`"
echo "$var"

The default is to disable variable parsing (except whitespace), and eval is there to override it.
Kevin Barry

Is this really intended as Bash, or as POSIX shell (aka are you using "#!/usr/bin/env bash" or "#!/bin/sh")? If it's POSIX shell, then eval's the only way you can accomplish what you want.. I'd rearrange things a little bit to avoid spawning a subshell and make quoting a little bit nicer:

eval "tcp_ports=\$${prefix}_tcp_$application"

If it's Bash, I'd use arrays instead of a space-delimited list, though for port numbers I suppose it doesn't really make a difference since port numbers obviously can't contain spaces.

Two things you can do.
1) Control the environment and PATH variables. You can clear the environment and set the values you need at the start of the script.
2) Use full absolute paths. Not portable, but you could test for the location of programs in the start of the script and assign it to a constant variable. Many service scripts are written this way. It may be important to control the library paths as well.

#! /bin/sh

### BEGIN INIT INFO
# Provides:          boot.fuse
# Required-Start:
# Should-Start:      boot.udev $local_fs
# Required-Stop:
# Default-Start:     B
# Default-Stop:
# Short-Description: Start and stop fuse.
# Description:       Load the fuse module and mount the fuse control
#       filesystem.
### END INIT INFO

PATH="/sbin:/bin"
...

There are two cases where "#!/usr/bin/env <shell>" can be dangerous.

When the PATH variable includes a path that points to a bad version of the shell which is an suid program.
When the PATH variable includes a path that points to a bad version if the shell and the script is run by the root user.

You might want to look at the manpage for system().

       The system() function should not be used by programs that have set user (or group) ID privileges. The fork() and exec family of func-
       tions (except execlp() and execvp()), should be used instead. This prevents any unforeseen manipulation of  the  environment  of  the
       user that could cause execution of commands not anticipated by the calling program.

In your example above, you could use:
tcp_ports="$(eval builtin echo "\$${prefix}_tcp_${application}")"

Thanks

Nice, easy, clear, simple and short, just like it should be.

-Paavo

PS. I use "#!/bin/bash" - this is a Fedora 12 x86_64 system.

Originally Posted by tuxdev Is this really intended as Bash, or as POSIX shell (aka are you using "#!/usr/bin/env bash" or "#!/bin/sh")? If it's POSIX shell, then eval's the only way you can accomplish what you want.. I'd rearrange things a little bit to avoid spawning a subshell and make quoting a little bit nicer: eval "tcp_ports=\$${prefix}_tcp_$application" If it's Bash, I'd use arrays instead of a space-delimited list, though for port numbers I suppose it doesn't really make a difference since port numbers obviously can't contain spaces.

Originally Posted by tuxdev Is this really intended as Bash, or as POSIX shell (aka are you using "#!/usr/bin/env bash" or "#!/bin/sh")?

According to my understanding of the env man page, /usr/bin/env bash (without any -* or <NAME>=<VALUE> arguments to env) is functionally equivalent to simply bash. Am I the wrong stick end having?

In the context of a she-bang, they aren't equivalent. The she-bang does not do a PATH search at all, so if you use "#!bash", it'll try to use a file called "bash" in the current directory as the interpreter. "/usr/bin/env bash" is indeed equivalent to just "bash" on a regular shell prompt.

Originally Posted by tuxdev In the context of a she-bang, they aren't equivalent. The she-bang does not do a PATH search at all, so if you use "#!bash", it'll try to use a file called "bash" in the current directory as the interpreter. "/usr/bin/env bash" is indeed equivalent to just "bash" on a regular shell prompt.

Thanks; that's illuminating but I still don't understand the benefits of #!/usr/bin/env bash in

Originally Posted by tuxdev Is this really intended as Bash, or as POSIX shell (aka are you using "#!/usr/bin/env bash" or "#!/bin/sh")?

What is the functional difference between #!/usr/bin/env bash and #!/bin/bash (apart from searching $PATH for bash which is not, to my mind, beneficial)?

You stated the difference. The advantage is portability. Some Distro's or Unix's may have bash or sh located in /bin, one that tends to the ksh may have bash installed in /usr/bin. Your script using "#!/usr/bin/env" will run as long as bash is in the environment.

There are potential dangers. Especially for some BSDs and Unixes where SUID scripts are allowed.

Originally Posted by jschiwal You stated the difference. The advantage is portability. Some Distro's or Unix's may have bash or sh located in /bin, one that tends to the ksh may have bash installed in /usr/bin. Your script using "#!/usr/bin/env" will run as long as bash is in the environment. There are potential dangers. Especially for some BSDs and Unixes where SUID scripts are allowed.

Thanks jschiwal -- finally I've got it; that's fully clear and useful now