Re: [PATCH v2] exec: run final pipeline command in a subshell in sh mode

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 6/9/20, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Peter Stephenson wrote on Sun, 07 Jun 2020 18:24 +0100:
>> On Sun, 2020-06-07 at 09:55 -0700, Bart Schaefer wrote:
>> > On Fri, Jun 5, 2020 at 1:42 PM brian m. carlson
>> > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
>> > >
>> > > I will tell you that as a practical matter, nobody writing code for
>> > > sh
>> > > expects the last command not to be run in a subshell and consequently
>> > > lots of code is practically broken in this case with zsh as /bin/sh.
>> > >
>> >
>> > I believe you, but would be curious to see an example.
>> >
>> > For what it's worth, I'm not opposed to this patch.  I think it's
>> > pretty unlikely that anyone is invoking zsh as sh and still expecting
>> > to be able to (for example) pipe into read to set variables in the
>> > current shell.
>>
>> Yes, since I'm still here, that's my position too.
>>
>> Our general position on consistency is that we'll try our best to
>> keep native mode compatible, while with sh compatibility we'll
>> try to be like other shells and not worry so much about what zsh
>> used to do.
>
> This being the case, I'm happy to defer to consensus.  I won't object
> to an entry in the list of incompatibilities in README, though.
>
> I can't speak for Mikael, of course.

I was only objecting to the commit message in the first place :). I
think the arguments for including it are not very convincing but I
don't really have any at all for not including it.

Surely it must be very rare to run something like
foo | shellfunction
and *depend* on shellfunction not setting any global parameters? Why
would you make shellfunction set global parameters in the first place
if you depend on them not being set? And then only when being piped
to? It seems so strange to me. Anyway, those are just arguments
against the sanity of shellscript writers, not against the inclusion
of the patch.

-- 
Mikael Magnusson