From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-30734-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 25187 invoked by alias); 15 Oct 2012 09:07:29 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 30734
Received: (qmail 20902 invoked from network); 15 Oct 2012 09:07:27 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.2
Received-SPF: neutral (ns1.primenet.com.au: 209.85.219.43 is neither permitted nor denied by SPF record at ntlworld.com)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:x-originating-ip:in-reply-to:references:date
         :message-id:subject:from:to:content-type:x-gm-message-state;
        bh=Al+4KYWLFkT2GtXs5DmxfGpHPi7pYpdfENQWhtu7tmI=;
        b=Z4KvLIk3dKTN7JaSMX8zNICv3kq5TF/NgEVpgdaXQr+X4iM+sefYSXpaXQXXF8Ebs2
         9aOj9DP7biIDr9kf+exPugInmNNlLiMyxZflvjDwwLDoXM61ViIGdp85jANRggj85XW5
         GvwanJ86HkTBd1hgR7L/IV3oyy3ACmK0rLzMisJodTT5uLJz3oQjjzx8g3xZc5HarRoJ
         pFqPCkJsjiyIUFL8hGTo2FQt/LVeY4PoCwpYySzzdBo8r6HvJJCo/cY+/uyP9v3Z+5/3
         CIBFm1xhwiPGyg37XG2nOTbZqRDAcUw1AKi9aydkWCm9v+Z5pceb+U9QaO03C2C3npA2
         GmUA==
MIME-Version: 1.0
X-Originating-IP: [80.239.194.50]
In-Reply-To: <CACeGjnUhwg+ehAX0CAge+Hye3m7xE6vA-5XCwenf4tTXS7kMtg@mail.gmail.com>
References: <CACeGjnUhwg+ehAX0CAge+Hye3m7xE6vA-5XCwenf4tTXS7kMtg@mail.gmail.com>
Date: Mon, 15 Oct 2012 10:07:21 +0100
Message-ID: <CAECNH1THarUQspV5r0CkjrEjxUHm7Jp7_J3VG1Q8ph=L3FZmxQ@mail.gmail.com>
Subject: Re: Segfault in =( ) substitution
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@zsh.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlgKe/5dAkynPNrZ6lnzgV1ua5f+lV3o81qWLtYla/CeXV3I1YVMVknlDvKImHr7AC05ZUz

On 15 October 2012 04:30, Vin Shelton <acs@alumni.princeton.edu> 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