Re: GNU Parallel Bug Reports which shell is invoked (Was: why is parallel invoking a shell **by default** and associated bugs)

[Stephane Chazelas]

2015-05-31 23:57:10 +0200, Ole Tange:
> On Sun, May 31, 2015 at 10:14 PM, Stephane Chazelas
> <address@hidden> wrote:
> > 2015-05-31 16:22:15 +0200, Ole Tange:
> >> On Tue, May 26, 2015 at 9:39 AM, Stephane Chazelas
> >> <address@hidden> wrote:
> >>
> :
> >> > $ bash -c "parallel 'readlink /proc/\$\$/exe;true' ::: 1"
> >> > /bin/zsh5 # my interactive shell
> >>
> >> Yikes. I did not know that some shells use exec if it is the only command.
> >
> > Most shells do.
> 
> Bash and zsh do, but it seems those are the exceptions:
[...]

Maybe there's been some confusion here. What I meant is that most
shells (though I should have said most Bourne-like shells as
they are those called by system()/popen()) execute the 
command in the shell's process.

A test for that would be
"$shell" -c ps
not showing a process for the shell.

All of bash, zsh, mksh, ksh88, ksh93, yash and some versions
of dash (the change was reverted at some point as it was causing
problem) at least do. Of those, bash and mksh only do it when
there's only one command. None do it if there's a trap on EXIT.

[...]
> > Or you can use "; exit".
> 
> Does not work for (t)csh, whereas '&& true' works, so I will put '&&
> true' in the manual.

Good point.

> 
> > Again, that transforms a death by signal n to a exit(128+n) (and
> > wastes a process).
> 
> Wasting a process is the least of my worries.

I can see that. You could save a lot BTW by avoiding running
that extra perl -ane to process the ps output (and do the
process in parallel's perl interpreter).

> I really do not feel the shells' behaviours adhere to Principle of
> Least Astonishment.
[...]

How and when shells fork processes is internal soup not meant to
be visible to the user as long as it works as documented. IMO,
it's like being astonished at how C compilers reorder code for
optimisation.

-- 
Stephane