From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d230cfb2 for ; Thu, 25 Apr 2019 19:48:57 +0000 (UTC) Received: (qmail 15800 invoked by alias); 25 Apr 2019 19:48:37 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23938 Received: (qmail 28855 invoked by uid 1010); 25 Apr 2019 19:48:37 -0000 X-Qmail-Scanner-Diagnostics: from mail-lj1-f177.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.1/25426. spamassassin: 3.4.2. Clear:RC:0(209.85.208.177):SA:0(-1.9/5.0):. Processed in 2.642332 secs); 25 Apr 2019 19:48:37 -0000 X-Envelope-From: schaefer@brasslantern.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.208.177 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KyTI4y9zSGeDEHnpLzd+v0F50x/UgalqOYOzXGVjAaA=; b=JOOyir81VvVmJ8gSpU+Ic9VzwMoJcodSvhuG6PGX6B74RNxmhHHorqgMt5VSoaxzG7 RnBJCJhludm8/rDIkveWOOVsdhekjlbIeoa50UJw1xZxlInb8G5e9CE4nNNZ7V7/tqPC nFA+oY/NTrKVdyaUhemr4y3auKiZ4F73owZodNrf+1Wc379JyMpDe6yeuumaCnMZRzgR tZ7hz02G/tFxnz7M/gHvcgbAj+Exp7bEX64aUjrpFCJpzoSUAbFUmANYendBzwgD+3Oe jU3Q3XAyC+QGotZIJ51gnrdAqUmyQSy0b6JEzznifutqmg7CxibfWDitMPmm2myxTD4f x9Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KyTI4y9zSGeDEHnpLzd+v0F50x/UgalqOYOzXGVjAaA=; b=OcC3htFeebSdv5DBjdEmsv+nF8oR7beJ0/mNhLje7k+Q5W6FKVwl4BomnWb3L04duB d0smHngrm0vW9yC8WAc8lHzeoHPMva9i1a+GQ03uYANdxfvaGEsXIqoB7ikW1xLaTbfZ s8m0ZAf8wHOb9UBwpz2QYsim2OEYdv8Qif4s5h0Qx9JVxq/tY7UBAGdX6Zmkevlwdjma tLH2HDkM+PMNr43jYXjvPsni3WdZjjQmQi2/bFQtrJ3b3fFoic1wQ9d8gELYMXo6uiif dPiY5NBEJjV79ep7PnVYLWJNX9ya+PXqYb9O2NNfSEwYc3DCa5RRP5RLKgcFNrSvk3CI bMKQ== X-Gm-Message-State: APjAAAVqiIhfPbl/c+tzkpug2M1v6G2fhUKA51ObiMehotijRsUNRusN toND+DIrv99d/BPVeaeP41lfGNsxhIovqnaXqCPmxRE+9G4= X-Google-Smtp-Source: APXvYqxkXmCeq5CYNxThG2A9RUo87siiI9QNK6NYqpILK1CkhejcNtUwAqEGUF0x3xGcgfiacMTQoyhg9GEEzu96vvY= X-Received: by 2002:a2e:7a09:: with SMTP id v9mr21258064ljc.167.1556221678965; Thu, 25 Apr 2019 12:47:58 -0700 (PDT) MIME-Version: 1.0 References: <20190410125557.GA19114@cventin.lip.ens-lyon.fr> <1554902053.6252.6.camel@samsung.com> <20190410141113.GD15169@cventin.lip.ens-lyon.fr> <1554907186.6252.12.camel@samsung.com> <20190411104040.GA29775@cventin.lip.ens-lyon.fr> <20190424123144.GA21402@zira.vinc17.org> In-Reply-To: From: Bart Schaefer Date: Thu, 25 Apr 2019 12:47:46 -0700 Message-ID: Subject: Re: print builtin preceded by parameter assignment To: Zsh Users Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 9:00 AM Bart Schaefer wrote: > > This is not related (and is not actually the case). TZ does not > remain exported. What remains is that the settz() call has changed > the current timezone of the zsh process to be something that differs > from the value of the TZ environment variable. > > difference with LC_ALL is that it is recognized as semantically > meaningful to the shell, so it has special code to invoke setlocale() > whenever it changes. TZ is not specially handled in the same way. If we want to simultaneously fix the former bug and also begin handling TZ the way Vincent expects, we would have to introduce get/set functions for TZ analogous to those for LC_*, so that settz() is invoked on TZ value change the same way setlocale() is on LC_* changes. Further we would have to examine uses elsewhere of settz() and localtime() [most notably in prompts and zsh/datetime] to be sure that those either aren't needed, or that they correctly save/restore the timezone if forcing one that differs from $TZ (or from the orginal starting timezone when TZ is not set).