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

[Achim Gratz]

Ole Tange writes:
> 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.

I humbly suggest you don't do that or at least make it optional.  It
would make using a fancy interactive shell but running commands with
something much more lightweight, for instance via

SHELL=/bin/dash ENV=.shinit parallel …

needlessly cumbersome.

> 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.

What files get read under what circumstances is intricate, but
documented.  Your best shot at getting consistent results is probably to
use (BASH_)ENV or --rcfile.  If that configuration should also be
present in your interactive shells, simply source the same file from
.bashrc or .profile.

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

That's actually the third file it sources and only if .tcshrc doesn't
exist.  But anyway that this can't be suppressed at all is one of the
things that makes (t)csh suck as a script processor (I still use it as
my login shell).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds