From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2393 invoked by alias); 27 Jun 2017 13:52:41 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41370 Received: (qmail 13310 invoked from network); 27 Jun 2017 13:52:41 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f195.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.128.195):SA:0(-2.3/5.0):. Processed in 0.805235 secs); 27 Jun 2017 13:52:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,RCVD_IN_SORBS_SPAM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: layus.on@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.128.195 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5so5/5TUKFjZ0Ox0km8lC9XPo5mqZ7vqyZ4TgA77W2g=; b=i1uQ7ifdfkaN6rheOKVM4uO8J5kwd06sTbwV7cjyCpL7WpTfHIPYmKtoBmEs4fL3qo 0qNeET7GFp4FQexbJ4nHs5vsidiZqmXR+RZ3sP5gBObctMz9XvdnRhIil7QBYrMpkCqh f4HoYEaliyr60SEvsovR3y0672WdJKpfIJs7NeztHBu4f/wdBbnFtPwnkjVcHoZJEAX4 9GNXEpAxrSq/jcTT2rn/kXneya5FGUvq3z5xbgGRe5wtY2dN3Zd4K3sVo1gNbQJ4gWHT VDxbKBO5X8h5X7xB4f/XBoKWU+EQfCUvro6p/uikIa8oW5Bja4iwij+90deL8AKuz/Uy 0G7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=5so5/5TUKFjZ0Ox0km8lC9XPo5mqZ7vqyZ4TgA77W2g=; b=M+3f4CS8+UifJcHs/1zcWZsvKQK0k56pBDaOImtwH5ADmE6ZyQb5AEPjI0b9YcFHRr fY4XFyzCJ6g+sDYPH5CkKmUuWnRDybIbfoZ0Ov1PJYvVWI6tqucP2Rz6SuMRVInhZ9tJ Vb+hrvb4pb+TH8aLJJVlTr5SvKXvfh3OrdSX28HxmPg6RhI3sNJ6Oynsfuz3l8F9Qh3H 4K6FW48uYL9vSljdBIgxHnFBr0ajVZCQHwmQdbWWNs3LjgBL3SuHWiwrh1bx3Gvit4Tx 3kDxU7wtffRcwkDA9VDuMgcVnWZO5wu7XWLo7mFOfyTH9O7YRjS2bbElT3NeM7z13P55 PAYA== X-Gm-Message-State: AKS2vOzXNjEWYj4N7NgAYO3qblHOPoODGRhcYTxkvaNA2Oh+Z0AB8Kk4 FxmSp0Fj9eWzTnJi X-Received: by 10.223.161.149 with SMTP id u21mr17834178wru.70.1498571551895; Tue, 27 Jun 2017 06:52:31 -0700 (PDT) To: zsh-workers@zsh.org From: "Guillaume Maudoux (Layus)" Subject: Race condition when setting TERM{,INFO{,_DIRS}} Message-ID: <2ad57c3b-f0c4-afd9-4789-ae50571c63e1@gmail.com> Date: Tue, 27 Jun 2017 15:52:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Hi, Half a year after submitting a patch to treat TERMINFO_DIRS like TERMINFO and TERM, I now see a race condition in handling these vars. Zsh handles these variables specially because ncurses looks for them in the environment of the current process. To make changes to these variables apply to zsh itself, they are exported to the process environment, where ncurses can find them. But there is a possible race condition between exporting these vars (setenv) and refreshing the ncurses handle (getent). In my case, when TERMINFO_DIRS is set from /etc/zshenv, the new value is ignored by ncurses. The same applies to the subsequent TERM=$TERM in /etc/zshenv. However, if I add a delay before TERM=$TERM, then the TERMINFO_DIRS update is seen, and the terminal is properly detected. Could it be that there are threads involved in zsh ? This seems really weird because the code looks sequential. Any hint welcome. -- Layus