From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,RDNS_NONE, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kj6E8-000COG-1B; Sat, 28 Nov 2020 19:49:48 +0000 Authentication-Results: zsh.org; iprev=pass (mail-oi1-f171.google.com) smtp.remote-ip=209.85.167.171; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-oi1-f171.google.com ([209.85.167.171]:32965) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kj6Dl-000C9a-3Y; Sat, 28 Nov 2020 19:49:25 +0000 Received: by mail-oi1-f171.google.com with SMTP id k26so9754690oiw.0 for ; Sat, 28 Nov 2020 11:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Y6mCZ8aiaH4KVbraUUsC90V/9oF4Cz5D9/PSXhAkPAw=; b=VF1Z7cS4+ZBGnTDvpVpO73Sw6a8UL/UfoD8BuLAewcbFVbCrPDIZ0SPPE/zIUqMX4i co9IC9LDihdhpH0xpnWfykfegGQMu7YLCUEc12gxPIU5QYHGfZbrb/XGhoqWmZnzdDLg /JQ9Oe+Q9PWz6YYVnk39NpWamB8TnOTsogSga6cTSf8YyeM6kfQTNtBzT5yFgpztSwIJ axKvfES2NPLvOvzzrxZkqfLrqbNJB0VIlNz8Si7DeKbwheNO9hhH9YA1n0ZEgxYumO8h FlX5ydaX15/pizUqLYE5OZOFlGasepTLOInQYpqKodaZPvtgU13dhYFmK1DXlCDuaBHo 9g1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y6mCZ8aiaH4KVbraUUsC90V/9oF4Cz5D9/PSXhAkPAw=; b=H+m5gMy11YYbsrQFWl7Kn5eaHhYzugZe4xduiPt7AIE8rz3fKTbRTMG8NE6IcYLE4C R3i2pkqb+l+ocql/B2+obfWRTiKBTpAxH/Ls92zn2oh9lOtivJPYkBoeCFnNLbaUJWmg 3kceicoTWqfNKP/gTSt8SeerL0qgWNhMxsps41lqb29w0GvT66+hvRznvaH0Q/MFoNJo wCL2xvXnlkGBZceGjJpzGJ3/bE+NwLsY52MYPO0pckGMEFxYYBvY8eodUZ9CjQKUdJNu z6GjeMgqWw25+xAHRbD+An9XQAlA/SYRTdKo2UePuv5disLofEjmslD6jn2jRKKV4CYr Y62w== X-Gm-Message-State: AOAM532plfkHAMzGlghAzg1gIPfGEIIKODad3lHdxcp/FsgaWmSMvgSG PF+GZguVfL/x5LpNS73kvMUj1L3gOH0atlVuVQBGgtwqiT1L6w== X-Google-Smtp-Source: ABdhPJzeABHwq/bUfx03QAgazchY5QgMRaVbMFle4ZR6sEnP66i5m09VMZhICzBlFOEW51SYLpXyeRhIPIejSSyQlWc= X-Received: by 2002:a05:6808:8c8:: with SMTP id k8mr9683572oij.84.1606592963343; Sat, 28 Nov 2020 11:49:23 -0800 (PST) MIME-Version: 1.0 From: Bart Schaefer Date: Sat, 28 Nov 2020 11:49:12 -0800 Message-ID: Subject: One possible answer to typeset vs. unset To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 47697 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Those of you who get zsh repository commit messages will have seen this already. Rather than send a patch here (yet), I've taken Daniel's suggestion and created a new branch. The changes address the issue that "typeset foo" creates $foo set to an empty string, by concealing the internal value rather than altering the way internal values are defaulted. You can see these changes by checking out the "declarednull" branch. I did not (yet) introduce an option or emulation control of this, though I did test a build where it was predicated on emulation, and the current default behavior is unchanged in that case. This imposes the following changes, most of which can be amended if desired: A typeset variable with no assignment triggers NO_UNSET warnings when the name is used in parameter expansion or math. Incidentally, there is no existing test that covers this; that is, NO_UNSET is tested only with names that have never been declared or names that have been explicitly unset. The typeset -AEFHLRTZailux options are applied upon the first assignment to the variable. Explicit unset before the first assignment discards all of those properties. If any option is applied to an existing name, historic behavior is unchanged. Consequent to the foregoing, the (t) parameter expansion flag prints nothing until after the first assignment, and the (i) and (I) subscript flags also print nothing. I think the latter is one of the more problematic consequences, especially for some completion functions. One that I forgot in the commit log: The behavior of "typeset foo; typeset foo" is changed. Previously the second typeset would output the current setting of foo: foo='' With these changes, that outputs nothing. However, once a value has been assigned the historic behavior is restored, so "typeset foo=bar; typeset foo" outputs foo=bar Furthermore, "typeset foo; typeset -p foo" outputs only typeset foo The bash behavior of "unset foo; typeset -p foo" is NOT used. This is called out as an emulation distinction, not a change. The test cases have not been updated, so several now fail. The test harness has been updated to declare default values, because otherwise the harness itself is the first thing that breaks.