From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id DE185230A9 for ; Fri, 23 Feb 2024 23:33:20 +0100 (CET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1708727600; b=rW8c5gYrRJeSMPtZEBmmxDdi9s3dLBwJfbSOEMor/kgvnblI1+4NGlUn/wUlfN23aQb8xcbgOu cq5OJrTny0N3Kia7BIH28/poaONMiGRy2cRTFLfDUyEJfR4yEcXC+tjzDzjMbbeqMWpY3bQ81B HvwXv24rkcXRwMMolPrYAb3AYOR7y9EsSfd3IgAiZcfe0ZyyRxj5zy+GECcI1W9X1KoZf/tis+ p1P85GjEC7ZRM3HC5mn7CSCUSw9VQ5Y2bfcrby+0CiVkl/CWgDIFvCddodhz3pcgwucHwkFA1N sDDrVRfDxDthDqM6hSZJX/XfichvxVEKfD6T4R6O25+UbQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ej1-f42.google.com) smtp.remote-ip=209.85.218.42; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1708727600; bh=2XWeoEBZLRN5VA5rrPMmq9JEs9sC+pgWKZfEEvJpCmo=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:DKIM-Signature:DKIM-Signature; b=kQy73Ac8oEdf8jDq73ci24ztl+H7FPo3kl4mF/k9fSTgkknzVFw4qjZ7miqrNx/hmLn5q+A224 h93aZozP6huIUjhIEjysmFgUJeG8ipSnxUseKIApQfeh4ZLMkEbEeZJpzBQ+en35eLUdPOsJqH xURQD+V1Z6eVbhCy7ulpafC5viddHd08QJtFLS7zbJQ+cwf0iBsUBkAJpNFXALnqmYbgGMswBG x9ifxqlaCk1s4XUszT9NHHs2n451qHofcFH5LboPqrHBkT8vyGOymVv/fk2GtgefUDDZsfQPaD rJ6fZ1rzLompRlmbiVkOc3UOS5Zyko1jgJkiw6waWxmU2w==; 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:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Cc:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=lCLHKSrvqUj6m1QX+rhXGGeeDdyPvx3W6Mj2v8iVcPs=; b=FABkFEFw8bymPGlGv/ZNLQvrO4 o7/RNKoPQ2WD9ztsA8x+SoGMGGd6rM/wVPZhJOKob08rRjkJBLXCJXGBrdwBFOHEljA1yE8nIBt5i IgZSBOBU9zBczHiXHMAH+giVIRIMvf3tgmBoMMsuU7KH5Ks2eI5itNDvocOuZ0ZT9koAsR7oTJ0dg BmVlfaZdIw4EBrcEC/YYPL0qR0aVkpB6U3/p1qhEMunmTnaiX3QWUJk5ZAwXYnfsBRbQNeioDpvRV q0vtkyQx5vq0rK02WtlS/On3dPIlOQRl2ljBCEJK2WcX/3Ab1tLmiXSVGJB4KUtrrqe0THgBiutjK gHWzGYZQ==; Received: by zero.zsh.org with local id 1rde6a-000P0A-30; Fri, 23 Feb 2024 22:33:20 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ej1-f42.google.com) smtp.remote-ip=209.85.218.42; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ej1-f42.google.com ([209.85.218.42]:56483) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rde6H-000Oik-E1; Fri, 23 Feb 2024 22:33:03 +0000 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a3e4765c86eso127702566b.0 for ; Fri, 23 Feb 2024 14:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20230601.gappssmtp.com; s=20230601; t=1708727581; x=1709332381; darn=zsh.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lCLHKSrvqUj6m1QX+rhXGGeeDdyPvx3W6Mj2v8iVcPs=; b=WB7E9I7pEbQBTMJGUF50uk+aTSE7IF0hV6HluSfA09z1SXla1YW/+Ak0rUuM45Ux/b MnecdF/K00CEyN/WLKiN7CfGC+Ga/9fOeGnBP6TEjczIamDXfbkhPRgOwigfe3PXy+7X 3jUQ+Udmhg2Os3YZEK1Ixms8jV6Ee7vF1MyhcgtMiee6cOVgdxBuvuFi5c7E2sUSQwVz cNitIrY1HH6jpqQl0xaRDr/+o/3MlVx96zT+AsndoXD1U/5QZN0J5CkI4HPQWsUQsp/o FvZPQKPPca5u8ooyb3AffI/MsI/ExvV/TUL3ZfUamF/j3DzpxFhjKt9s1zUTkY1yWegm H6+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708727581; x=1709332381; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lCLHKSrvqUj6m1QX+rhXGGeeDdyPvx3W6Mj2v8iVcPs=; b=Gcc05EeQa/aU+v1Ox904Zyl+gvUH7bkwVhql1bV907SiyaI8ObfzbBnLH+L+14I3X+ bti0Gn1R1NKMkQoVy+m0Jfi7uRkpBU3VATzaNZNcq1m12bPIN+XVKTZiiVS3MvLHcyb+ mN1AgJUIZaRIyLqFUJ5x9LWxUGH/wncS1+BDHgtDTX1ZBK+HhfRYZn2vgfTBAfnu4Y0v PWsV9gPbYIp+FO4hd4IoJ/w65ZjyQpuu0g46Gu3ggPg47bGmyztRs6+GpJQ6WleXfuz0 FyjYTUp74HjO12BweEAFR9OfsgjiDah6QJZnhloItd00gCk5cyaBypreXK56kRkwa+4i x3OA== X-Gm-Message-State: AOJu0YxrVaSeNBZBbbOC+CYdxT1RoNRSu01YmG6BZZGdzFE9aMoBMIQk X9tFcDQm1o25InV4cBsVAokBjlVVwEZX5ZRhI9JSI6fOlLbzGewQjdJIKIrUDFk8P3BFTBfifrL g7R+0sL12sP6ydnWzjD5wOt4pjGqhvfd1v35K+9+EyFskUzSq+g== X-Google-Smtp-Source: AGHT+IGOc1osQR6+ECxhMhbCOxe6Ur6Y9U0XVTQ+hlbJj/5qlmGq5F/TJtvznkv0O2gaexiERGPV/xRqM7LO7uWtOh8= X-Received: by 2002:a17:906:b5a:b0:a42:cd69:4ce9 with SMTP id v26-20020a1709060b5a00b00a42cd694ce9mr267490ejg.31.1708727580702; Fri, 23 Feb 2024 14:33:00 -0800 (PST) MIME-Version: 1.0 References: <20240220193911.avnmcqfliwltkj5m@chazelas.org> <20240221194534.o2mufin7orng6ttg@chazelas.org> <20240221202150.tccftcqbxqqexq4x@chazelas.org> <20240222072313.7woy5vxvt4fbxyhj@chazelas.org> <20240222075528.eruaoosiuhmcrdsy@chazelas.org> <20240223192717.tczrbc63fei7d4m2@chazelas.org> In-Reply-To: <20240223192717.tczrbc63fei7d4m2@chazelas.org> From: Bart Schaefer Date: Fri, 23 Feb 2024 14:32:49 -0800 Message-ID: Subject: Re: Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) To: zsh workers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Seq: 52585 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 Fri, Feb 23, 2024 at 11:27=E2=80=AFAM Stephane Chazelas wrote: > > 1. whether user-supplied text in messages should be output raw The question here is whether error message is about MISTAKENLY user-supplied text, vs. INTENTIONALLY supplied. My assertion is that it's only the caller of zerr() and related functions that can interpret whether the text is intentional or not. I would argue that your math examples are mistakes, at least as far as the parser could possibly "know". > 2. Whether internally in the code the data should be passed > "metafied" or not to zerr* functions. That still only means we need one way to instruct the function to skip "nice"-ing and one way to say not to. Skipping ahead a bit, we'll come around again later ... > > $ printf '%d\n' $'1+|a\x83 c' > > zsh: bad math expression: operand expected at `|a^@c' > > Should have been: > > zsh: bad math expression: operand expected at `|aM-^C c' You're missing part of my point here. % printf '%d\n' $(( 1+|a\x83 c )) zsh: bad math expression: operand expected at `|a\x83 c ' That is IMO more useful than either of "^@" or "M-^C " and is down to the difference between using printf on a $'...' string (which is interpreted before printf even gets its mitts on it, and two layers before the math parser does) vs. using the actual math parser directly. This has nothing to do with how the string is passed to zerr() and everything to do with how printf and parsing interpret the input -- by the time the math parser actually calls zerr() it can't know how to unwind that, and the internals of zerr() are even further removed. I would therefore argue that these examples are out of scope for this discussion -- these examples are not about how zerr() et al. should receive strings, they're about how the math parser should receive them, and needs to be fixed upstream e.g. in bin_print(). More relevant to this discussion is that math errors are one of the two existing callers using the %l format, so any attempt to improve this is going to require changing those calls anyway. > For 1, IMO, when the error message is generated by zsh, it > should go through nicezputs(). zsh should decide of the > formatting, have it pass escape sequences as-is would make it > hard to understand and diagnose the error. Agreed in concept, but there's a difference between errors actually generated BY zsh, and errors with user input that zsh is reporting. For example, the same literal string might be a file name generated by globbing, or it might be something the user typed out in a syntactically invalid command. There's no way to put intelligence about how to format those into the guts of zerr(). The question of whether to go through all 500 calls to zerr(), zwarn(), etc., and "fix" them is something entirely else. Presently we have just the one known case of wanting something different for ${var?msg}. > For 2, it looks like zerrmsg expects its input metafied and as > you say, that input in most cases is likely to be metafied > already. Not metafied would mean either we couldn't pass text > containing NUL, or we'd need to pass it as ptr+len. There's already a way to pass text not containing NUL (%s) and a way to pass text as ptr+len (%l). There are a vanishingly small number of uses of the latter (2 callers out of the ~500 total call examples). There's exactly one case so far of wanting output to contain NUL, and per the "only caller can interpret" assertion, it seems worthwhile to use %l for the NUL case and let the other 3 callers decide to "nice" the strings they pass (or not). This not only skips extra metafication needed to use the proposed %S, but also simplifies the implementation of %l, and requires the addition of only 1 or 2 lines of code to each of the two existing callers using %l (maybe zero lines of code in the case of yyerror()). > %S also passed metafied, but no nicezputs. That requires metafy in the caller followed by unmetafy in zerr(). Much easier to remove code from %l than to add it to a new %S, especially given that we're editing the solitary caller where %S would be used. > Now, my previous message was showing there were quite a few > issue with the metafication and possibly with the nicezputs'ing > and/or multibyte handling. Fine, but not fixable in zerr() and friends. > [...] > > $ printf '%d\n' '1+|=C3=83=C3=83=C3=83=C3=83=C3=83=C3=83' > > zsh: bad math expression: operand expected at `|\M-C\M-c\M-c\M-c\M-c\M-= c\M-^C...' > > I picked =C3=83 because it's a letter from the latin script, so you > can even use it in variable names Sure, but it's not being interpreted as any part of a variable name here, because you put it in quotes and then passed it to printf. Remove the "|" and you get something worse: % printf '%d\n' '1+=C3=83=C3=83=C3=83=C3=83=C3=83=C3=83' BUG: unexpected end of string in ztrlen() zsh: bad math expression: operand expected at `\M-C\M-c\M-c\M-c\M-c\M-c' 0 % printf '%d\n' $((1+=C3=83=C3=83=C3=83=C3=83=C3=83=C3=83)) 1 (Also a bit weird that the first \M-C is capitalized and the rest are not?) Still not a problem to be resolved in zerr(). > > $ ((1+|=C3=83=C3=83=C3=83=C3=83=C3=83=C3=83)) > > zsh: bad math expression: operand expected at `|=C3=83=C3=83=C3=83=C3= =83\M-C...' > > In that case, metafication OK, but character cut in the middle. Still not zerr()'s fault and needs to be addressed where the number of bytes for %l is being calculated in checkunary(). > > % ((1+|=C3=83=C3=83=C3=83=C3=83=C3=83=C3=83)) > > zsh: bad math expression: operand expected at `|=C3=83?=C3=83?=C3=83?..= .' > > It seems rather worse to me. That's because of the way I chose to lift nice-ifying up into checkunary() for testing the approach. It's hard to be consistent there, given the foregoing business about different formats being sent down from printf vs. $((...)), and it's also why I said "no patch without feedback".