I have a problem with executing commands with "$" or other spacial
characters in it.
exec echo $PATH -> can't read "PATH": no such variable
exec echo \$PATH -> $PATH
exec {echo $PATH}-> couldn't execute "echo $PATH": no such file or
directory
It's like a vicious circle.
I know I can simply use "set env(PATH)" but that would only match this case,
and I have others more difficult ones.
Thanks in advance for any lead.
Greeting, Sascha
The first word in each command is taken as the
command name; tilde-substitution is performed on
it, and if the result contains no slashes then the
directories in the PATH environment variable are
searched for an executable by the given name. If
the name contains a slash then it must refer to an
executable reachable from the current directory. No
``glob'' expansion or other shell-like substitutions
are performed on the arguments to commands.
If you must have a shell, you can do
exec bash -c "echo \$PATH"
but it might be better to let Tcl do expansions for you:
exec echo [set env(PATH)]
The Tcl glob command can be used for file wildcard expansion.
exec does do pipelines and redirection, but it does those itself, not
through a shell - check the syntax in the man page because it is
probably not what you expect.
Of course, the result of [exec echo [set env(PATH)]] is the same as the
simple substitution of the array element, $env(PATH), so the whole
exercise is just going round the long way. If it is the user that's
supplying the shell script though, it's best to use the [exec bash -c]
approach; that works really rather well.
Donal.
The OP said he knew that, I was just following his trivial example.
> If it is the user that's
> supplying the shell script though, it's best to use the [exec bash -c]
> approach; that works really rather well.
>
Agreed.
Eric
Or, equivalently:
exec bash -c {echo $PATH}
which will probably lead to less quoting with more complex scripts.
-- Neil