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

[Kempf, Stephen]

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.

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.

~Steve

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Ole Tange
Sent: Tuesday, August 05, 2014 3:51 AM
To: Kempf, Stephen
Cc: address@hidden; address@hidden
Subject: Re: GNU Parallel Bug Reports User .rc files interacting with 
parallel's sub shells

On Tue, Aug 5, 2014 at 3:06 AM, Kempf, Stephen <address@hidden> wrote:

> I’ve run into a case, which I believe is a bug, in which a user’s .rc 
> file (for whichever shell is in the SHELL env var) interferes with the 
> commands run by parallel.  For example:

In the next release $SHELL is ignored if GNU Parallel can figure out which 
shell it is started from, so if started from tcsh, 'tcsh -c'
will be used to start new commands.

That, however, does not address your concern.

I have not used tcsh seriously for around 15 years, so let me refer to bash.

If my .bashrc contains function definitions, then I expect these to run just 
like they would on the interactive command line. In other
words: I would find it ideal if:

  $ foo bar

would give the same output as:

  $ parallel foo ::: bar

even if foo was defined in ~/.bashrc

However, at least my installation of bash does not do that. If 'foo()'
is defined in .bashrc it is not accessible in parallel. In other words it seems 
my installation of bash does what you expect, but not what I expect.

Testing the same on an account that uses tcsh seems to be exactly
opposite: ~/.cshrc is sourced first.

> # .cshrc
>
> module purge

I have no ideal what 'module' does, so I will skip to your working example.

> If parallel is intended to be an easy-to-use replacement for foreach 
> loops, then I’m pretty sure it would be a rare occurrence for it to be 
> desirable for the sub shells to source the user’s .rc file.

I would tend to disagree: If a command is available when I login, I expect to 
be able to use that in GNU Parallel - no matter whether it was defined as 
script, alias or function.

> Therefore I would like to
> request that the sub shells be invoked with an appropriate option (-f 
> for tcsh; --norc for bash, etc.) to skip sourcing the user’s .rc file 
> - or at least, for this behavior to be made available as a new command line 
> option.

Let us hear what others think. Maybe there is a behaviour from other tools that 
will make sense to adopt?

> Complete, runnable example using an echo in the .cshrc as a proxy for 
> environmental destruction:
>
> #.cshrc
> echo "I'm in your shell, sourcing your .cshrc!"
>
>> env SHELL=/bin/tcsh parallel echo ::: a b c
>
> I'm in your shell, sourcing your .cshrc!
> b
> I'm in your shell, sourcing your .cshrc!
> a
> I'm in your shell, sourcing your .cshrc!
> c

/Ole