Open Gautham opened 3 years ago
Hey, this does indeed seem like a valid use-case. But for now there are a few ways you can work-around this limitation. For instance:
if [[ $3 = my_idA* ]]; then ...
Example 1:
startEnvA() {
exec startEnv "$@"
}
startEnvB() {
exec startEnv "$@"
}
async_start_worker my_env_worker
async_job my_env_worker startEnvA EnvA
async_job my_env_worker startEnvB EnvB
Example 2:
async_job my_env_worker "print my_idA; startEnv EnvA";
async_job my_env_worker "print my_idB; startEnv EnvB";
Possible (future) solutions:
async_job
, e.g. async_job --id envA ...
id
for uniqueness check as well (when it is used)
Problem Statement
Currently, the callback fn is only passed the name of the executable/fn in the job. If I'm dealing with multiple jobs using the same executable that differ only in args, then the callback fn can't help me disambiguate which job ran.
Sample Usecase:
I'd like to have my callbackFn to provide some info on the env (envA vs envB) as well. However, $1 in callbackFn is just
startEnv
today. Is this possible today?Alternatives