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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25975 invoked from network); 27 Jun 2022 21:44:37 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2022 21:44:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Subject:Cc:To:From:Date: References:In-Reply-To:Message-Id:Mime-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=ut5jdO3IY0CNzKiBuZDkP67tylGLtFgl2I2IUlSiWQU=; b=qNyNsKvqVErhAaN9YP13kdYQ43 jfzhq/+lsqQ1ZjxXB+XfptPcPuyAM7/GH8gAvCuD9/gS21uott6+fQhBxF10Ypjn/Rfa3klUlf5Et fl1t9oPjtm4zeRCYAuGOfq90GOwa0UiY9PRDi4FVh1nbYTR3mVPjhee5TzxneTb0RhAYh7MwHWiOZ bugCkPqFCJbbDlrAqwRVKJFPkwk3ExwHZCIf/4XyJhropHbZSFnVUFSjoNNlq0uRtATuxQK+3qJ/N mQ0dVtDBRjWxrGZFj2TK9wfzgGsTjilT6lRD1dIWYjw5qJOp8vPKd9pU+82Xxg7GggS7Pm4TOPUfZ 0O0ZugQA==; Received: from authenticated user by zero.zsh.org with local id 1o5wX7-0008iA-7m; Mon, 27 Jun 2022 21:44:37 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1o5wWr-0008NW-Cp; Mon, 27 Jun 2022 21:44:21 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id AF4B327C0054; Mon, 27 Jun 2022 17:44:18 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Mon, 27 Jun 2022 17:44:18 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegiedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderreejnecuhfhrohhmpefnrgif rhgvnhgtvggpgggvlhojiihquhgviicuoehlrghrrhihvhesiihshhdrohhrgheqnecugg ftrfgrthhtvghrnhepgeeuleejgfdvkeejgfejgeetkeekteejheekteeliedtkeegudeu geetgeehkeefnecuffhomhgrihhnpeiishhhrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhihvodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdduudehudekjeejtdegqdduudelvdejfeekhedqlhgrrh hrhihvpeepiihshhdrohhrghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: iaa214773:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 790CB31A0062; Mon, 27 Jun 2022 17:44:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7 Mime-Version: 1.0 Message-Id: <3accd9cb-aede-41ce-96e6-f3e175392b9d@www.fastmail.com> In-Reply-To: References: Date: Mon, 27 Jun 2022 17:43:48 -0400 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: "Michael Smith" Cc: zsh-workers@zsh.org Subject: Re: Bug: 'export FOO' not idempotent Content-Type: text/plain X-Seq: 50388 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: On Mon, Jun 27, 2022, at 5:11 PM, Michael Smith wrote: > Environments tested: > - macOS 12.4, M1 chip, zsh 5.8.1 (x86_64-apple-darwin21.0) > - Ubuntu 20.04.4, zsh 5.8 (x86_64-ubuntu-linux-gnu) > > If I repeat 'export FOO' to mark an environment variable not give it a > value, in bash it consistently does not show up in 'env': > $ export FOO > > $ env | grep FOO > > $ export FOO > > $ env | grep FOO > > > but in zsh the 2nd invocation will set it to an empty string: > $ export FOO > > $ env | grep FOO > > $ export FOO > $ env | grep FOO > > FOO= This was discussed in workers/47531 and the ensuing thread. https://www.zsh.org/mla/workers/2020/msg01350.html It was resolved in zsh 5.9 with the introduction of the TYPESET_TO_UNSET option, but as per workers/47545, "[t]his is a long standing feature of zsh, so the default behaviour is not going to change." https://www.zsh.org/mla/workers/2020/msg01364.html > This is an issue only because a project I'm building uses an empty > export for documentation, and it makes that project annoying to work > with. Depending on a variable to be exported but unset is a curious design decision to say the least. -- vq