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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30342 invoked from network); 13 Aug 2023 18:55:13 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Aug 2023 18:55:13 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1691952913; b=H8D7fbEikV/To0/3aY2/QKJRcJFfYAiiKNKqsdp5/aUot9+vqlq95qyQX/moTN5ZC/cZNwEf5Q vOsAQKh5s9Bkf8LStkWPA0UmbfxxsPonuctVaeH8DjRR+yOsnu4zfVVagW+lrhfTA/TTJ/CA4m VeNVFVSVaZLcAvtixDgi7GTAb3eRTrmFrC3oSqg5k62gMMdj29vPFqfqX9BhXHy5pjAKeO3KYT phK5/jBgVeUJPwd6hOSyUoz5SLO+ntD9UaNc9aX41ja0522uZa47IT7R81N/tnGVgOK7YFRevI ItDDWPjubKEH+ZKqj0/XmtjLgyiFD5sEnYdC6CNylcKlsg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-4323.proton.ch) smtp.remote-ip=185.70.43.23; dkim=pass header.d=opndev.io header.s=protonmail2 header.a=rsa-sha256; dmarc=pass header.from=opndev.io; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1691952913; bh=Y2i3DPifNn/4EVMWKHXm+6JdCp1EYcs4SHr6mwCtbJU=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:MIME-Version: References:In-Reply-To:Message-ID:Subject:Cc:From:To:DKIM-Signature:Date: DKIM-Signature; b=QAw1nwKTAJEKOCpOrh1Lu5pWT/SuAhW6d8pN6asfHbSCFc6yaZIPdZzEZY7VyFy+TWEHHECaRk WN4zjsWiI9FrUA85tzwxMtGZmJ6b+NqtCD8WhhwyiHosUpOkOYUGYA4Ul0AmxY7XK3NhqQNckO bU046SRdjxYRUvOt1v6azOou6ciWy1IBi21RUaiDAQol6EM8LBS+WPKgMYsvUVjgZksQ4ZqAdL VcO+wki/Y2cGmCSjjgnYMjCcDERU8aB2QfxR6dkiQhofyffm0sZIf+pBbVyx+AfrAQFXGt/Z+q Bo5b6A7RuToGFgftsGaoCPkLsr4kV50vR6A1Xy/6XBcU7Q==; 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-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:From: To:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=nLS5COdyMNUlA3QdMqLtCKURGIDOiXjVD8k+jK8IWwE=; b=YFx04wDtQN7oAxR3EU75O+v++Y 65PacJLcbFfYkYudE4SZArqf4cWpVHGXJ4gvSqjrEwNbQp3y+3E5BEC2WH1H3Fj1sl4GZ6wJDXk9L 1TxZuNC5cKUe2x5Bozlb4PF7RLkpMBKlDLwtAfLe0J0UO4h0x6kebKcqEj6kZO91T+KMQlcW7RcM7 oUGKbjS3qKsam8cZcoe4p793byezK9eVTptV6DEcQIVKfjCGOsT9o2P4qTnnTdrOtii0f1QtF6YeS Ipu8ANK98Gx9YuKhRYLr2VgVDKDOI9PhGupqTz2QE8czmKSfYgerKT+X65ztECqf3JOJ2vstMdgXE I2nIgEYA==; Received: by zero.zsh.org with local id 1qVGF6-000MyW-OD; Sun, 13 Aug 2023 18:55:12 +0000 Authentication-Results: zsh.org; iprev=pass (mail-4323.proton.ch) smtp.remote-ip=185.70.43.23; dkim=pass header.d=opndev.io header.s=protonmail2 header.a=rsa-sha256; dmarc=pass header.from=opndev.io; arc=none Received: from mail-4323.proton.ch ([185.70.43.23]:25495) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1qVGEp-000Mfi-1n; Sun, 13 Aug 2023 18:54:56 +0000 Date: Sun, 13 Aug 2023 18:54:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opndev.io; s=protonmail2; t=1691952893; x=1692212093; bh=nLS5COdyMNUlA3QdMqLtCKURGIDOiXjVD8k+jK8IWwE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GPO3caoFW6fmYCRR9g94HGhC7sUXD13X79Ld6De0hP4g7nv6pTy2h3ia2sBnfwoV9 1ZyS2cirj9n7VnN3sXzJebz5VzGw/IGmDmlKgoksSoRL48NbdBWGHh4A3JK96oBVgQ vGpBGm9Ac11pUhyh5pErldlIsVnVDuRh/PLavNFbYQytdh7P4VOMFfJt4h4KrWYGWK SZb/f/gmiU3IER4H2cGdoMfOi4xjhSjD/XCjeGCCskHdraf6eMOQM43JUJxdmR1g/m 6+nEl13RXqN4qN1CMq81XvGQONDfwh7bH3VyvsdiiU45vt48I5gSWI4/5yNE+UnKEj Gj69rOX26lnRQ== To: Daniel Shahaf From: Wesley Schwengle Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Show patchlevel in version string Message-ID: <513c6cff-bb1a-485a-b043-0959f80cd3e6@opndev.io> In-Reply-To: <20220410213529.GD27526@tarpaulin.shahaf.local2> References: <20210903173803.4005670-1-wesley@opperschaap.net> <20220410213529.GD27526@tarpaulin.shahaf.local2> Feedback-ID: 16776580:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Seq: 52045 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 4/10/22 17:35, Daniel Shahaf wrote: > Wesley Schwengle wrote on Fri, Sep 03, 2021 at 13:38:03 -0400: >> After this patch is applied, you get to see the following version string >> after you configured zsh with `--enable-custom-patchlevel=3D$(git descri= be)': >> >> $ ./Src/zsh --version >> zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c) > > Adding the git revision there makes sense, I suppose, but why should > this only be done when that configure option is used? The git revision > is added to ZSH_PATCHLEVEL (which is a shell variable, not an > environment variable) by default, without needing any configure flags. > > Or another perspective: CUSTOM_PATCHLEVEL is used to cause > $ZSH_PATCHLEVEL to be set to something other than its default. So, > why shouldn't the #else branch emit the default value of $ZSH_PATCHLEVEL? > > tl;dr: Why not include the (build's default) value of $ZSH_PATCHLEVEL in > the output? I want to back track a little from my original answer from last Friday. How do we progress, this patch in itself could be merged I think without having to have all kinds of other logic to always show it. I think this is a nice first step. I'm willing to work on the other solution to always include a patch level based on some other logic. However I placed the patch level between the brackets because I wasn't sure if/how we want to display the version. As stated in the commit body of the patch: > Because I'm not aware how downstream deals with a difference in version > strings I've decided to add it to the vendor/os type bit. Debian for > example uses `debian/5.8-6+b2' as a patch level. This would probably > break scripts which expect `zsh x.y.z' if the patch level replaced the > ZSH_VERSION string. $ zsh --version zsh 5.9 (x86_64-debian-linux-gnu) I would expect (or assume) that Debian wants to keep showing the 5.9 version and not the debian/5.9-4+b4 bit. This would make parsing the ZSH version tricky, eg, zsh --version | awk '{print $2}' suddenly gives a different output than scripts would expect. If you run zsh --version from a bash shell you get the version string, you don't have access to the $ZSH_VERSION shell variable. Now, if we use this ZSH_PATCHLEVEL in any build, what logic are we going to apply? * Do we remove the CUSTOM_PATCHLEVEL output from the --version call if the CUSTOM_PATCHLEVEL equals the ZSH_VERSION string? * Do we replace the ZSH_VERSION with the CUSTOM_PATCHLEVEL if the ZSH_VERSION includes -dev, eg 5.9.0.1-dev becomes 5.9-240-g51ae2a5ff To reiterate. I'm open to add improvements to always displaying the patch level, but I would love to see this patch merged before we agree on more things. I think adding it to the OS/Vendor bit has very little impact on scripts but it aids us in seeing what is being used (for example when build from source). Cheers, Wesley -- Wesley Schwengle E: wesley@opndev.io