bug-parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ole Tange
Subject: Re: GNU Parallel Bug Reports User .rc files interacting with parallel's sub shells
Date: Tue, 5 Aug 2014 12:51:07 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]