Re: GNU Parallel Bug Reports User .rc files interacting with parallel's sub shells

[Ole Tange]

On Tue, Aug 5, 2014 at 9:13 PM, Kempf, Stephen <Stephen.Kempf@amd.com> wrote:
> Thanks for your reply.  You're absolutely right about aliases and functions - 
> in fact, lack of that behavior is a pet peeve of mine regarding xargs and 
> find -exec.  I habitually forget that unlike environment settings, alias and 
> function definitions are not inherited by subprocesses.

Can we change that?

It cannot be changed from within the perl program (as it cannot see
either aliases, functions or variables), but having seen how you can
tweak Bash into "exporting" assoc arrays
(http://stackoverflow.com/questions/24977782/accessing-associative-arrays-in-gnu-parallel)
I am thinking it might be possible to do.

For bash I am thinking a function that will gather aliases, functions,
and variables; put them into an exported function (similar to the
assoc array idea above), and then let GNU Parallel activate that
function automatically if it is set.

parallel() {
  # [... gather environment/aliases/functions into parallel_environment() ...]
  # make parallel_environment visible to GNU Parallel
  export -f parallel_environment
  # Inside GNU parallel:
  #    if set parallel_environment(): prepend it to the command to run
  `which parallel` "$@"
}

and then use this function as the normal parallel command.

Can something similar be done for (t)csh?

> For the purposes of this thread, "module load" prepends $PATH with the path 
> to a particular non-standard application's binaries, and "module purge" 
> undoes this.  You can find more info at http://modules.sourceforge.net/.
>
> Our current workaround is to invoke parallel with 'env SHELL=/bin/sh parallel 
> ...'.  This will not work in the next release if parallel figures out it was 
> called from a tcsh shell and ignores $SHELL.  After thinking some more about 
> it I would lean towards introducing a new env var (perhaps "$PARALLEL_SHELL") 
> to tell parallel exactly what shell to use.  I too am interested to hear what 
> the community has to say about it, though, so let's see what they come up 
> with.

$SHELL has a well-defined meaning: It is the login $SHELL. For that
reason I would feel better about $PARALLEL_SHELL. But I am not sure
that is sufficient. When you use parallel as your shebang parser like
this:

    #!/usr/bin/parallel --shebang -r traceroute

which shell should be used to call traceroute?

In many cases you don't care, but if you give your shebang'ed script
to someone else, and they use a different login $SHELL, then it might
cause your script to fail. So also here you need a way to say which
shell to use.

The most obvious solution is to introduce a new option: --shell

    #!/usr/bin/parallel --shebang -r --shell /bin/sh traceroute

This would override the autodetection.


/Ole