I have created many BL batch jobs, each residing at their own specified job location, which all executes multiple underlying batch jobs and jobs, which runs the same nsh script. The nexec script is a generic wrapper that find out the job's name, copies a general script from the depot location that has similar path tree as the job name, to the client and does an nexec -e with the script.
The issue I have is since the script it executes is a general script that performs a specific function pertaining to the job's name, it cannot be scripted specifically for that environment. In our unix env, we usually set environmental variables, so any subshell or script that is called can recall those variables. But with nexec, none of my variables can pass through.
I am currently passing parameters to the nsh script, which passes all of them to the script via
nexec -e SCRIPT $@
But since the nexec script is used by all, I have to have imagine all flagged parameters that will ever be used and have them defined in the front of param list (since nsh's getops doesn't know how to parse them properly when they are not in the front), and every job that calls that nsh script has to have all the unused flags/parameters turned off. Plus now I have to have a different jobs to call the same nsh script, since the parameters passed to the nsh script is cuztomizable only at the job level, not at the batch job level.
I did try to set env variables this way:
nexec -e sh -c "env ENV1=something ENV2=something2 SCRIPT $@"
But the passing of $@ to the subshell, especially quoted ones does not want the shell to expand (such as '*' char) is not handled properly. Even if I parse $@ in the nsh script and pass them properly as quoted individual parameters, the end quote of sh -c still appears at the wrong place and things gets passed wrong. nsh -ncq didnt help.
Besides the parameter passing, my other workaround is to set have global and local env files in the depot location, and copy that over to the client. But now I have to have all my scripts source those env files, and I have to keep all the multiple copies of env files in sync (ksh, csh, perl all have different formats, so they need different env files).
What I really wanted was to have the environmental variables be set at the job or batch job level, and have it propagate to the nsh script, then to the eventual script it runs. But that seems impossible.