Re: Segfault in =( ) substitution

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On 15 October 2012 04:30, Vin Shelton <acs@xxxxxxxxxxxxxxxxxxxx> wrote:
> Starting very recently, I'm getting a core dump from this code:
>
> [[ -n $pat1 ]] && diff1=( =(perl -p -e $pat1 < $file1) )

What's happened here is that =(...) failed because there was no longer
an associated job for it to attach itself to within the variable
assignment.  This is exacerbated by the fact that error handling
in getoutputfile() is poor.

The change in behaviour comes from my patch to invalidate thisjob
within execsimple().  I still think that's correct: the "thisjob" the
expansion was (previously) assigning itself too would be whatever
thisjob happened to be left set to after the last command ran, which
isn't the right thing to do (except by coincidence).

The right thing to do would be to ensure that assignments that have
complex substitutions in aren't marked as "simple".  Failing that,
marking array substitutions as not simple might be good enough.

Now I have to understand parse.c...

pws