# calling an environment variable in a ps-watcher config file

I am trying to use ps-watcher to monitor my system and make sure a given number of worker threads are working on a task. If I hard code the number of workers into the config file for ps-watcher, it works great. However I would like the number of workers to be pulled from an environment variable named WORKERS. This seems simple, but has proven to be a pain.

Here's an example config file that works:

[myProg]
trigger = $count<5 action = /home/ubuntu/startWorkers.sh  I pulled the following from the man for ps-watcher: This parameter specifies the condition on which a process action is fired. The condition is evaluated with Perl eval() and should therefore return something which is equivalent to true'' in a Perl expression. Which makes me think I should use $ENV{VARIABLE} as I would in Perl. So I tried the following:

[myProg]
trigger = $count<$ENV{WORKERS}
action = /home/ubuntu/startWorkers.sh


to which my ps-watcher log recorded the following:

Use of uninitialized value in concatenation (.) or string at (eval 6) line 1 (#1) (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a "" or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. To help you figure out what was undefined, perl will try to tell you the name of the variable (if any) that was undefined. In some cases it cannot do this, so it also tells you what operation you used the undefined value in. Note, however, that perl optimizes your program and the operation displayed in the warning may not necessarily appear literally in your program. For example, "that $foo" is usually optimized into "that " .$foo, and the warning will refer to the concatenation (.) operator, even though there is no . in your program.

I'm at a bit of a loss. Any help would be appreciated.

I agree with the single quote idea, but also double-check that the variable is actually exported by doing a print "$ENV{'WORKERS'}\n"; before the eval. Perhaps you are not exporting the variable into the children. • Also do a print of$trigger or whatever you are evaluating to double-check the resulting perl code is what you want. – Seth Robertson May 20 '11 at 19:19
• @JD Long: Then run printenv > /tmp/x in an evaluated context, or ps axewww while the program is running, to check for the environmental variable. – Seth Robertson May 20 '11 at 19:39
\$ENV{'WORKERS'};