Re: factor-parallel test failure with SHELL=zsh

[Pádraig Brady]

On 02/07/15 08:08, Pádraig Brady wrote:
> On 02/07/15 06:19, Jim Meyering wrote:
>> I was surprised to see that the factor-parallel test was failing.
>> However, when I installed the very latest binaries early in my
>> path, it would succeed once again.
>>
>> Turns out that when SHELL=zsh is in my environment,
>> the split-run "$SHELL -c factor" command was using an
>> PATH environment that did not have the usual .../src/: prefix,
>> so it would use whatever other version of factor it could
>> find in that PATH value.  In my case, it would use factor
>> from 8.23, which lacks recent patches and makes the test
>> fail. To show that, I ran a little experiment:
>>
>> With zsh, it prints nothing for me:
>>
>>   $ PATH=bogus:$PATH zsh -c 'echo $PATH'|grep bogus
>>   $
>>
>> with bash or sh, it works as expected and prints the prefixed
>> value of $PATH.
>>
>> This appears to be due to the fact that I set zsh's path via
>> my ~/.zshenv file, and that file is sourced unconditionally.
>> Perhaps what I am doing is best avoided? I've been doing
>> it for many years, so far without such a problem.
>> I'll send this now and investigate more later.
> 
> Seems you're not alone as I had another user
> report 'factor not found' on BSD.
> 
> Personally I only set $PATH for login shells (.bash_profile).
> 
> This could be a general problem with `split --filter`
> using `$SHELL -c`, with potential side effects
> like ignoring the current $PATH etc. ?
> 
>> For me, an obvious work-around is to set SHELL=/bin/sh
>> or similar.
> 
> Yes or to avoid the slight chance of /bin/sh also resetting the path
> you could directly reference the binary as follows.
> I slightly prefer setting the SHELL though.

Yes given we should also set SHELL in tests/split/filter.sh,
I'll apply the attached in your name later on.

thanks,
Pádraig.

split-SHELL.patch
Description: Text Data