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_H3, RCVD_IN_MSPIKE_WL,RDNS_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kiOaV-0008gY-Nz; Thu, 26 Nov 2020 21:13:59 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ot1-f45.google.com) smtp.remote-ip=209.85.210.45; 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-ot1-f45.google.com ([209.85.210.45]:36603) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kiOa7-0008S2-WF; Thu, 26 Nov 2020 21:13:36 +0000 Received: by mail-ot1-f45.google.com with SMTP id y24so2930625otk.3 for ; Thu, 26 Nov 2020 13:13:35 -0800 (PST) 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=iXjh2T0bkMHfuLJVCjCEFP0QCSDCO4VQ2FlAT7GFOMc=; b=0BINu/acMoz9QpZJ00W7OSkPobp8YhNWiIx84bUUhNP93/roTCJVnCIbkRa1Gn6OA7 nj3wUkARrqHc8nvPTZSuFmvGLO0Fr3TPu1UJivoF+nYApukMxYrIkKJNqAg0xgc1tGs4 +cjzPpbE3C4zJvfeDSRg6QdcZRVkvq14L2Va7vaBP8HwJH52Ye+3CXpfh/biYYqpVMXI P3g4/KB3Tq/dyNrZhWpAmVmlNC1u7Gskbxvd6sJTFKakMo4f3BG+ErE7R+HxqezK8mz9 a+jnFqg9CpvRvc2uClivF3ShZdj3Hcgvoc0hImRrQqNowcpSZQfiz1AsqCeRhSnYdMpA thDw== 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=iXjh2T0bkMHfuLJVCjCEFP0QCSDCO4VQ2FlAT7GFOMc=; b=aqzcoGEpLH1+KnvxxMDeYlG1SILtYpgNLCc5FwnBwzQH12yD0lRv3AiSSkgraa5GSG F1jjaga3VIpgUx5/Y7vKkFJazfdg0YAEfGPQmYAW/yRLvuuTWUxRBSEEhaaG3oSIqpuL h61eZHCrWyGETe4IAcmprt6mEkv7S1lYx+2t9UJIdvUSSmhjOPjoT5ajwKzbxogL+ai4 w4nKziAuOBCXP4QCUZWVnFfa1mboCYW5SitLlbjdA8J0kSAMGwwQGf2g8IYxqagsSpa9 Au+qiWQaO5P/OUFS1oiBHXeunJqUEZWFYATJEUJr8Fn2wi9TpShmDlXR0wIaRpS0KtvR 3NNg== X-Gm-Message-State: AOAM532MPjcNKR811kGUApoxLe+nVXEss5xR4s8CRVPWfp+1J7dvnACZ oTfDWLpy3aoN6pSVDGEKTydBLVg4O79tl4U93yUXUx439o3h/g== X-Google-Smtp-Source: ABdhPJyg8iOjC2pZQeuR/2j5KUk9NerzA9CXmIJUv+tzv3OtT4JVZblwAW10jmVABX4dD5EzBbcAcrO+RGuR++O4wnc= X-Received: by 2002:a9d:470c:: with SMTP id a12mr3487708otf.161.1606425214367; Thu, 26 Nov 2020 13:13:34 -0800 (PST) MIME-Version: 1.0 References: <20201125131921.vay7h3xk5qn4odgg@chazelas.org> <20201126061029.in5tpnrg5bplam5k@chazelas.org> <86243-1606389706.499549@-gQx.nNYG.4Z3k> In-Reply-To: <86243-1606389706.499549@-gQx.nNYG.4Z3k> From: Bart Schaefer Date: Thu, 26 Nov 2020 13:13:23 -0800 Message-ID: Subject: Re: More rabbit-holes with unset variables To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 47646 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: On Thu, Nov 26, 2020 at 3:22 AM Oliver Kiddle wrote: > > It appears that export VAR will not export an empty VAR even in zsh > (unless you do VAR=""). So zsh's not exactly consistent. > typeset [-x] is arguably just a variant of export. Neither is a variant of the other; "export" is an alias for "typeset -xg" that happens to be implemented as a reserved word. > This does change how I regard zsh's behaviour. It isn't zsh taking a > different but equally valid approach on an extension but an sh > incompatibility. It once was a bug even if now too entrenched. It doesn't export the empty string at the time the parameter is declared, but it does consistently set it to empty string internally: % Src/zsh -f % export FOOBAR % typeset -p FOOBAR export FOOBAR='' % If it were NOT set, as after "unset FOOBAR", then "typeset -p" would print nothing. > It does make the KSH_TYPESET option somewhat less appropriate because > this effect also applies to sh emulation. We could do this when EMULATION(EMULATE_KSH|EMULATE_SH) instead of on an option. If we are in fact limiting it to variables with no "strong type" type then it really is sufficient to create an unset variable, except that we somehow have to signal to "typeset -p" that it should print the declaration even though the variable appears to be unset. The latter raises the question of whether we want the Bash behavior of continuing to print the declaration even after an explicit "unset", which differs from ksh (cf. my first message in this thread).