From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 15:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 65659@debbugs.gnu.org, bug-bash@gnu.org Cc: austin-group-l@opengroup.org X-Debbugs-Original-To: bug-coreutils@gnu.org, bug-bash@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16934962054414 (code B ref -1); Thu, 31 Aug 2023 15:37:02 +0000 Received: (at submit) by debbugs.gnu.org; 31 Aug 2023 15:36:45 +0000 Received: from localhost ([127.0.0.1]:56799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbjiu-000198-Sy for submit@debbugs.gnu.org; Thu, 31 Aug 2023 11:36:45 -0400 Received: from lists.gnu.org ([2001:470:142::17]:43558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbjir-00018t-Hd for submit@debbugs.gnu.org; Thu, 31 Aug 2023 11:36:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbjiY-0008I7-Cy for bug-coreutils@gnu.org; Thu, 31 Aug 2023 11:36:25 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbjiS-0003ES-Kt for bug-coreutils@gnu.org; Thu, 31 Aug 2023 11:36:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693496175; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=EU7pYyv0r5pWH0YFfqWoDl3QH4avRV5opoBuGLh37yI=; b=CtQ7sFyuQb4r4hNHBcqWorcQioApM2W0d+n15aJu5H2z5IoMPEjDNt+5F3EquPTWL1dlwO C8jTIdFpybib8rRSsUC5DT9J0IkASWnLDaxPUw88mbFrK1X+RUMRJ+eRqEJE6NrjsarlqW I4R/9K5ljChjT9lOlj+9e7iyXr110pg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-378-MNgZqVq_PquQX4tl-A5ECQ-1; Thu, 31 Aug 2023 11:36:09 -0400 X-MC-Unique: MNgZqVq_PquQX4tl-A5ECQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 14E008087B9; Thu, 31 Aug 2023 15:36:09 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54458401E63; Thu, 31 Aug 2023 15:36:05 +0000 (UTC) Date: Thu, 31 Aug 2023 10:35:59 -0500 From: Eric Blake Message-ID: MIME-Version: 1.0 User-Agent: NeoMutt/20230517 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=eblake@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In today's Austin Group call, we discussed the fact that printf(1) has mandated behavior for %b (escape sequence processing similar to XSI echo) that will eventually conflict with C2x's desire to introduce %b to printf(3) (to produce 0b000... binary literals). For POSIX Issue 8, we plan to mark the current semantics of %b in printf(1) as obsolescent (it would continue to work, because Issue 8 targets C17 where there is no conflict with C2x), but with a Future Directions note that for Issue 9, we could remove %b entirely, or (more likely) make %b output binary literals just like C. But that raises the question of whether the escape-sequence processing semantics of %b should still remain available under the standard, under some other spelling, since relying on XSI echo is still not portable. One of the observations made in the meeting was that currently, both the POSIX spec for printf(1) as seen at [1], and the POSIX and C standard (including the upcoming C2x standard) for printf(3) as seen at [3] state that both the ' and # flag modifiers are currently undefined when applied to %s. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html "The format operand shall be used as the format string described in XBD File Format Notation[2] with the following exceptions:..." [2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05 "The flag characters and their meanings are: ... # The value shall be converted to an alternative form. For c, d, i, u, and s conversion specifiers, the behavior is undefined. [and no mention of ']" [3] https://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html "The flag characters and their meanings are: ' [CX] [Option Start] (The .) The integer portion of the result of a decimal conversion ( %i, %d, %u, %f, %F, %g, or %G ) shall be formatted with thousands' grouping characters. For other conversions the behavior is undefined. The non-monetary grouping character is used. [Option End] ... # Specifies that the value is to be converted to an alternative form. For o conversion, it shall increase the precision, if and only if necessary, to force the first digit of the result to be a zero (if the value and precision are both 0, a single 0 is printed). For x or X conversion specifiers, a non-zero result shall have 0x (or 0X) prefixed to it. For a, A, e, E, f, F, g, and G conversion specifiers, the result shall always contain a radix character, even if no digits follow the radix character. Without this flag, a radix character appears in the result of these conversions only if a digit follows it. For g and G conversion specifiers, trailing zeros shall not be removed from the result as they normally are. For other conversion specifiers, the behavior is undefined." Thus, it appears that both %#s and %'s are available for use for future standardization. Typing-wise, %#s as a synonym for %b is probably going to be easier (less shell escaping needed). Is there any interest in a patch to coreutils or bash that would add such a synonym, to make it easier to leave that functionality in place for POSIX Issue 9 even when %b is repurposed to align with C2x? -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: [PATCH] printf: add %#s alias to %b References: In-Reply-To: Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 18:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: coreutils@gnu.org Cc: 65659@debbugs.gnu.org Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169350677621669 (code B ref 65659); Thu, 31 Aug 2023 18:33:02 +0000 Received: (at 65659) by debbugs.gnu.org; 31 Aug 2023 18:32:56 +0000 Received: from localhost ([127.0.0.1]:56989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbmTP-0005dQ-PA for submit@debbugs.gnu.org; Thu, 31 Aug 2023 14:32:56 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:50467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbmTN-0005dH-H4 for 65659@debbugs.gnu.org; Thu, 31 Aug 2023 14:32:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693506764; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5TAiwziRHS56H9d7YNRPaiL7CeJ5B1UVLPe6Msp56UI=; b=RlxgXNDaW/ZCabW/Q1h+R04ZUzFffrTkeRVMCXkn5zEGk7nZ6GoqMICetuq95DwF9shXeT JhCo2tvptTtDtB0Vw5VMHjM4kfqhS3kmWfW/h/y4WneL5haNoGtqY3EFWbAx9/E1jQzlFO BWZ784UenSXbenQH6OuRH/lr9IPNtXI= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-341-0Kp8sjKaM62ef6fT62KqeA-1; Thu, 31 Aug 2023 14:32:41 -0400 X-MC-Unique: 0Kp8sjKaM62ef6fT62KqeA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ED22338041DB; Thu, 31 Aug 2023 18:32:40 +0000 (UTC) Received: from green.redhat.com (unknown [10.2.16.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id A3FB040C6F4C; Thu, 31 Aug 2023 18:32:40 +0000 (UTC) From: Eric Blake Date: Thu, 31 Aug 2023 13:31:57 -0500 Message-ID: <20230831183240.518692-1-eblake@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) POSIX Issue 8 will be obsoleting %b (escape sequence interpolation) so that future Issue 9 can change to having %b (binary literal output) that aligns with C2x. But since escape interpolation may still remain useful, POSIX suggested %#s (which is undefined in all versions of C) as a possible alias for the older %b behavior. * src/printf.c (print_formatted, usage): Support %#s as an alias for %b, in order to open doors to future repurposing of %b to binary output while still allowing access to its old behavior. * doc/coreutils.texi (printf invocation): Document it. * NEWS: Likewise. * tests/printf/printf-quote.sh: Add unit test coverage. Fixes: https://bugs.gnu.org/65659 --- NEWS | 9 +++++++++ doc/coreutils.texi | 3 ++- src/printf.c | 9 ++++++--- tests/printf/printf-quote.sh | 4 +++- 4 files changed, 20 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index c00ff0cf2..2e2acc7cd 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,15 @@ GNU coreutils NEWS -*- outline -*- numfmt options like --suffix no longer have an arbitrary 127-byte limit. [bug introduced with numfmt in coreutils-8.21] +** Changes in behavior + + 'printf' now treats the format sequence '%#s' as an alias for the + older '%b' meaning escape sequence interpolation. It is anticipated + that a future version of coreutils will change the meaning of '%b' + to output binary literals, comparable to the meaning being added to + printf(3) by C23, which will leave '%#s' (which C does not specify) + as the only way to access the older behavior of escape + interpolation. * Noteworthy changes in release 9.4 (2023-08-29) [stable] diff --git a/doc/coreutils.texi b/doc/coreutils.texi index 373a407ed..81a8ca4ff 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -13331,7 +13331,8 @@ printf invocation @item @kindex %b -An additional directive @samp{%b}, prints its +@kindex %#s +An additional directive @samp{%#s}, or its older alias @samp{%b}, prints its argument string with @samp{\} escapes interpreted in the same way as in the @var{format} string, except that octal escapes are of the form @samp{\0@var{ooo}} where @var{ooo} is 0 to 3 octal digits. If diff --git a/src/printf.c b/src/printf.c index 9670d8043..e8866d50e 100644 --- a/src/printf.c +++ b/src/printf.c @@ -38,7 +38,7 @@ Additional directive: - %b = print an argument string, interpreting backslash escapes, + %b, %#s = print an argument string, interpreting backslash escapes, except that octal escapes are of the form \0 or \0ooo. %q = print an argument string in a format that can be @@ -126,8 +126,9 @@ FORMAT controls the output as in C printf. Interpreted sequences are:\n\ "), stdout); fputs (_("\ %% a single %\n\ - %b ARGUMENT as a string with '\\' escapes interpreted,\n\ + %#s ARGUMENT as a string with '\\' escapes interpreted,\n\ except that octal escapes are of the form \\0 or \\0NNN\n\ + %b obsolescent alias for %#s\n\ %q ARGUMENT is printed in a format that can be reused as shell input,\n\ escaping non-printable characters with the proposed POSIX $'' syntax.\ \n\n\ @@ -509,7 +510,7 @@ print_formatted (char const *format, int argc, char **argv) putchar ('%'); break; } - if (*f == 'b') + if (*f == 'b' || (*f == '#' && f[1] == 's')) { /* FIXME: Field width and precision are not supported for %b, even though POSIX requires it. */ @@ -519,6 +520,8 @@ print_formatted (char const *format, int argc, char **argv) ++argv; --argc; } + if (*f == '#') + f++; break; } diff --git a/tests/printf/printf-quote.sh b/tests/printf/printf-quote.sh index d1671bd9d..33ce3018e 100755 --- a/tests/printf/printf-quote.sh +++ b/tests/printf/printf-quote.sh @@ -22,7 +22,8 @@ print_ver_ printf prog='env printf' # Equivalent output to ls --quoting=shell-escape -$prog '%q\n' '' "'" a 'a b' '~a' 'a~' "$($prog %b 'a\r')" > out +$prog '%q\n' '' "'" a 'a b' '~a' 'a~' "$($prog %b 'a\r')" \ + "$($prog %#s 'a\r')" > out cat <<\EOF > exp || framework_failure_ '' "'" @@ -31,6 +32,7 @@ a '~a' a~ 'a'$'\r' +'a'$'\r' EOF compare exp out || fail=1 -- 2.41.0 From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Chet Ramey Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 19:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: eblake@redhat.com, 65659@debbugs.gnu.org, bug-bash@gnu.org Cc: austin-group-l@opengroup.org, chet.ramey@case.edu X-Debbugs-Original-To: Eric Blake , bug-coreutils@gnu.org, bug-bash@gnu.org Reply-To: chet.ramey@case.edu Received: via spool by submit@debbugs.gnu.org id=B.16935090875659 (code B ref -1); Thu, 31 Aug 2023 19:12:02 +0000 Received: (at submit) by debbugs.gnu.org; 31 Aug 2023 19:11:27 +0000 Received: from localhost ([127.0.0.1]:59249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbn4g-0001TD-RS for submit@debbugs.gnu.org; Thu, 31 Aug 2023 15:11:27 -0400 Received: from lists.gnu.org ([2001:470:142::17]:47750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbn4e-0001Sx-VD for submit@debbugs.gnu.org; Thu, 31 Aug 2023 15:11:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbn4O-0003cn-GD for bug-coreutils@gnu.org; Thu, 31 Aug 2023 15:11:08 -0400 Received: from mpv-out-ksl-1.cwru.edu ([129.22.103.228] helo=mpv-out-ksl-1.case.edu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbn4L-0000pc-9h for bug-coreutils@gnu.org; Thu, 31 Aug 2023 15:11:08 -0400 Received: from mpv-local-ksl-1.CWRU.Edu (EHLO mpv-local-ksl-1.case.edu) ([129.22.103.235]) by mpv-out-ksl-1.case.edu (MOS 4.4.8-GA FastPath queued) with ESMTP id BCW49210; Thu, 31 Aug 2023 15:11:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=case.edu; s=smtp-primary; t=1693509061; bh=AWQb/d7kTg6d4JNjFXlXIVi1WWQwN69+nibl654VRig=; l=2069; h=Message-ID:Date:MIME-Version:Reply-To:Cc:Subject:To:References: From:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YZWUq13hOW0em/EX4ZaZomzH7TJ9ShmryhFqzs19YrSCnD1P8soIxqrTw2eekvTn4z pORmBQW2GSabSCHYHygym9cjmw1TVgWG8gQcn2ok/aZBcZn5x94qo2t54WIjQMITLnB SiLrd/gTc92Nm1L1ENxeqkEW8kMtXkBelE7z9UZG8WpqFJtfnn8K4zu3vY98LafRx9+ gvhTOD20gp3v/unEgtwUyGrslj1rSrPdTf6qoyCEoVvlkniZtu/n26otcVVO525kZcN 55x+dYjCZ8pBXKrUORuZZ3QWq+elO7ARrsS9JH2GrGLw6nX94qEYMS6Sd16tqZzhzej KUsY+iEQ== Received: from mail-qt1-f198.google.com (EHLO mail-qt1-f198.google.com) ([209.85.160.198]) by mpv-local-ksl-1.case.edu (MOS 4.4.8-GA FastPath queued) with ESMTP id CGH57710; Thu, 31 Aug 2023 15:11:00 -0400 (EDT) Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-41213943314so12385521cf.0 for ; Thu, 31 Aug 2023 12:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=case.edu; s=g-case; t=1693509060; x=1694113860; darn=gnu.org; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:cc:reply-to:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=AWQb/d7kTg6d4JNjFXlXIVi1WWQwN69+nibl654VRig=; b=GXAmqnD+PfDMjFa139twK2geNElu5BtbSf3CVKD8bDxw/7Shm3EoJDgxq7CX0ykXQQ rq8YFv5VWFG3I8y7BtA4dhQDc8Q02inbr+YnQb+f3Wn/QXXzCOH3VArKFOSao8bYrJBF QlVaCLllSUB3SK/fTocycUfHR2XQF6KVmtIHPiG5LQf3/fRrCOOYvKi52kIU83NT1CyD 3KUOi9Kn6M0nPy1h/7YEQxZUXOjAKJhm1jmbJwtWsFEyv4IzwlsyVjJUduZZQnMfBjjS lrSZa3QVIubelv/G0YWIZgBqXlkX5TerRz0TU4Sed1OZCZ6MhdR78dsng6/kDCGC0DgY zRQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693509060; x=1694113860; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:cc:reply-to:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AWQb/d7kTg6d4JNjFXlXIVi1WWQwN69+nibl654VRig=; b=S1sAPbFxevJ9r04LSXFqiJ++J191R19hqRtO2pukNArgmOUEBeKCHC7nLD/jahIzi0 JSk+DJqB7yjUhsSq/SvaDa4tfYehjGokkbYL3R9dTYl+UWjW4aBes6LsPdtJ6BdJXQ5z EgSLVlcSGLhpqoKKAFWY/O7YPWx5lSnbBMluwwjUCv6RVSWM9mnGLusyxzu7PdCSjiax q3npZ1z5xH0nsfnYVkxTixY16TUS1XhtF9ffuHOSM88azyI/S6gF/b0SZbCai35YwzrQ A8Wib0TF3UQFa1eNgPMVRlC/7QGKY9ve/XQRRVnjnRGzI9jmspHAIj+7BiIffOn8TH6J 0t0w== X-Gm-Message-State: AOJu0YzLj65zBlqOJKur6DKGZh02EDS+lTbqavSc8xhF8ODR7gWEzD9T FokKtkE+P82YT7rJ7gRVMvs+4M1Zry3raRA1L02Bgg3fJjQiwgLHSgJgQWAHrDs1h//Nws8tcM4 3Si9t1deS+mCW1YatAw== X-Received: by 2002:ac8:5844:0:b0:40d:4c6:bcdf with SMTP id h4-20020ac85844000000b0040d04c6bcdfmr458813qth.35.1693509060260; Thu, 31 Aug 2023 12:11:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFyh9vx+oGprfcYDRsq6XgON7dHfZ051Pg0EPFqQ6MGXYOMNOyspDFW6lcrJX5UtCeo9mna2Q== X-Received: by 2002:ac8:5844:0:b0:40d:4c6:bcdf with SMTP id h4-20020ac85844000000b0040d04c6bcdfmr458799qth.35.1693509059995; Thu, 31 Aug 2023 12:10:59 -0700 (PDT) Received: from [192.168.0.110] (cpe-107-10-245-158.neo.res.rr.com. [107.10.245.158]) by smtp.gmail.com with ESMTPSA id y21-20020ac85255000000b004109928c607sm832387qtn.43.2023.08.31.12.10.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 12:10:59 -0700 (PDT) Message-ID: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> Date: Thu, 31 Aug 2023 15:10:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US References: From: Chet Ramey Organization: ITS, Case Western Reserve University In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A742F8D.64F0E345.000B, actions=tag X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A742F18.64F0E5C5.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2016-11-06 16:00:04, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 162880b15345bcbf3b13e02aee8b3a84 X-Mirapoint-IP-Reputation: reputation=good-1, source=Fixed, refid=n/a, actions=tag X-Junkmail-Status: score=8/90, host=mpv-out-ksl-1.case.edu X-Junkmail-PrAS-Raw: score=8/90, refid=2.7.2:2023.6.26.145126:17:8.707, ip=, rules=__YOUTUBE_RCVD, DKIM_SIGNATURE, __X_GOOGLE_DKIM_SIGNATURE, __X_GM_MESSAGE_STATE, __X_GOOGLE_SMTP_SOURCE, __HAS_MSGID, __SANE_MSGID, __MSGID_HEX_844412, DATE_TZ_NA, __MIME_VERSION, __USER_AGENT, __MOZILLA_USER_AGENT, __HAS_REPLYTO, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __SUBJ_REPLY, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __TO_MALFORMED_2, __MULTIPLE_RCPTS_TO_X2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __HAS_REFERENCES, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __MIME_BOUND_CHARSET, __CTE, CTE_7BIT, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC2, __HEADER_ORDER_FROM, __RCPT_DOMAIN_NOT_TO, __REPLYTO_SAMEAS_FROM_DOMAIN, __DKIM_ALIGNS_1, __DKIM_ALIGNS_2, __FUR_HEADER, __ANY_URI, __URI_MAILTO, __URI_WITH_PATH, __URI_ENDS_IN_SLASH, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138 Received-SPF: pass client-ip=129.22.103.228; envelope-from=chet.ramey@case.edu; helo=mpv-out-ksl-1.case.edu X-Spam_score_int: -55 X-Spam_score: -5.6 X-Spam_bar: ----- X-Spam_report: (-5.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.478, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) On 8/31/23 11:35 AM, Eric Blake wrote: > In today's Austin Group call, we discussed the fact that printf(1) has > mandated behavior for %b (escape sequence processing similar to XSI > echo) that will eventually conflict with C2x's desire to introduce %b > to printf(3) (to produce 0b000... binary literals). > > For POSIX Issue 8, we plan to mark the current semantics of %b in > printf(1) as obsolescent (it would continue to work, because Issue 8 > targets C17 where there is no conflict with C2x), but with a Future > Directions note that for Issue 9, we could remove %b entirely, or > (more likely) make %b output binary literals just like C. I doubt I'd ever remove %b, even in posix mode -- it's already been there for 25 years. > But that > raises the question of whether the escape-sequence processing > semantics of %b should still remain available under the standard, > under some other spelling, since relying on XSI echo is still not > portable. > > One of the observations made in the meeting was that currently, both > the POSIX spec for printf(1) as seen at [1], and the POSIX and C > standard (including the upcoming C2x standard) for printf(3) as seen > at [3] state that both the ' and # flag modifiers are currently > undefined when applied to %s. Neither one is a very good choice, but `#' is the better one. It at least has a passing resemblence to the desired functionality. Why not standardize another character, like %B? I suppose I'll have to look at the etherpad for the discussion. I think that came up on the mailing list, but I can't remember the details. > Is there > any interest in a patch to coreutils or bash that would add such a > synonym, to make it easier to leave that functionality in place for > POSIX Issue 9 even when %b is repurposed to align with C2x? It's maybe a two or three line change at most. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 19:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake , 65659@debbugs.gnu.org, bug-bash@gnu.org Cc: austin-group-l@opengroup.org Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169351050617930 (code B ref 65659); Thu, 31 Aug 2023 19:36:01 +0000 Received: (at 65659) by debbugs.gnu.org; 31 Aug 2023 19:35:06 +0000 Received: from localhost ([127.0.0.1]:59269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbnRZ-0004f8-T7 for submit@debbugs.gnu.org; Thu, 31 Aug 2023 15:35:06 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:56382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbnRX-0004eZ-IW for 65659@debbugs.gnu.org; Thu, 31 Aug 2023 15:35:03 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D0A663C011BD4; Thu, 31 Aug 2023 12:34:48 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0WFWq919ir34; Thu, 31 Aug 2023 12:34:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 86A253C011BD5; Thu, 31 Aug 2023 12:34:48 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 86A253C011BD5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1693510488; bh=uQodGi7Vr0mbf0DQjK0JZnQt4XP8EospH/MSlFqd6Yk=; h=Message-ID:Date:MIME-Version:To:From; b=Nms2WTRpLK32AVa59/B1KnX8ys9KN5gtgOpk5CAF+bNcdKmtj/7o/wCdT9BIbku36 HDf5ZgOuqhKpa4WidAfBR60kHRjk5ShCCXgeusZ/+3MQOm25Tl60kqT372n9DdtFT8 gKHRzFQTLy/f3lgNq3z5pRgLYMeNg238sgOmvaADcOKmSR1Hnfx0vrwd/3FqS5hM+u 3jFtHd6B/3HHwDzsk3EewKoPNFuvbOekH+zL7ldysMHoYc6QyTvxe9u0MetekVvJ1o Eq9PHE84T4zaa5HOSOECgInX25sEo6r3IRIq3ZoXUssJnGdul0h7UeQUs+jUPolHsR exCh6L3d1rXNg== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4FZCNCy_KsDw; Thu, 31 Aug 2023 12:34:48 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 5B1283C011BD4; Thu, 31 Aug 2023 12:34:48 -0700 (PDT) Message-ID: Date: Thu, 31 Aug 2023 12:34:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) On 2023-08-31 08:35, Eric Blake wrote: > Typing-wise, %#s as a synonym for %b is > probably going to be easier (less shell escaping needed). Is there > any interest in a patch to coreutils or bash that would add such a > synonym, to make it easier to leave that functionality in place for > POSIX Issue 9 even when %b is repurposed to align with C2x? Sounds good to me for coreutils. From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 20:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Chet Ramey Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169351216130836 (code B ref 65659); Thu, 31 Aug 2023 20:03:02 +0000 Received: (at 65659) by debbugs.gnu.org; 31 Aug 2023 20:02:41 +0000 Received: from localhost ([127.0.0.1]:59292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbnsG-00081I-Ic for submit@debbugs.gnu.org; Thu, 31 Aug 2023 16:02:41 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:34810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbnsD-000819-GB for 65659@debbugs.gnu.org; Thu, 31 Aug 2023 16:02:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693512148; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YV9M/dA3S69zEx7NmzlVkpTn9Xgfvgl3PtY7wohsmjU=; b=Ly2qlZ8grcJ5yYyASMfa9L345mcb4cZ9pxIy4A/zTlb0fU4RA6Gxhvuuu60E7gHytiql7+ ZsbkTdO6DJG/ATuXJQmOeRSZrngOsfsiS0wYKo5ATbUWOO4mzo7dasTmeeZ4RIFkGUj4u7 Roo32S7TtUNNyiJCB5EQ7s87yhYhUiU= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-558-SY2VXu8-OHel6FcZg8cPzw-1; Thu, 31 Aug 2023 16:02:25 -0400 X-MC-Unique: SY2VXu8-OHel6FcZg8cPzw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 80CC92807D72; Thu, 31 Aug 2023 20:02:25 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4C7ED40C2063; Thu, 31 Aug 2023 20:02:24 +0000 (UTC) Date: Thu, 31 Aug 2023 15:02:22 -0500 From: Eric Blake Message-ID: <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> MIME-Version: 1.0 In-Reply-To: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> User-Agent: NeoMutt/20230517 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote: > On 8/31/23 11:35 AM, Eric Blake wrote: > > In today's Austin Group call, we discussed the fact that printf(1) has > > mandated behavior for %b (escape sequence processing similar to XSI > > echo) that will eventually conflict with C2x's desire to introduce %b > > to printf(3) (to produce 0b000... binary literals). > > > > For POSIX Issue 8, we plan to mark the current semantics of %b in > > printf(1) as obsolescent (it would continue to work, because Issue 8 > > targets C17 where there is no conflict with C2x), but with a Future > > Directions note that for Issue 9, we could remove %b entirely, or > > (more likely) make %b output binary literals just like C. > > I doubt I'd ever remove %b, even in posix mode -- it's already been there > for 25 years. But the longer that printf(3) supports "%b" to output binary values, the more surprised new shell coders will be that printf(1) %b does not behave the same. What's more, other languages have already started using %b for binary output (python, for example), so it is definitely gaining in mindshare. That said, I also agree with your desire to keep the functionality in place. The current POSIX says that %b was added so that on a non-XSI system, you could do: my_echo() { printf %b\\n "$*" } and then call my_echo everywhere that a script used to depend on XSI echo (perhaps by 'alias echo=my_echo' with aliases enabled), for a much quicker portability hack than a tedious search-and-replace of every echo call that requires manual inspection of its arguments for translation of any XSI escape sequences into printf format specifications. In particular, code like [var='...\c'; echo "$var"] cannot be changed to use printf by a mere s/echo/printf %s\\n/. Thus, when printf was invented and standardized for the shell, the solution at the time was to create [printf %b\\n "$var"] as a drop-in replacement for XSI [echo "$var"], even for platforms without XSI echo. Nowadays, I personally have not seen very many scripts like this in the wild (for example, autoconf scripts prefer to directly use printf, rather than trying to shoe-horn behavior into echo). But assuming such legacy scripts still exist, it is still much easier to rewrite just the my_echo wrapper to now use %#s\\n instead of %b\\n, than it would be to find every callsite of my_echo. Bash already has shopt -s xpg_echo; I could easily see this being a case where you toggle between the old or new behavior of %b (while keeping %#s always at the old behavior) by either this or some other shopt in bash, so that newer script writers that want binary output for %b can do so with one setting, while scripts that must continue to run under old semantics can likewise do so. > > > But that > > raises the question of whether the escape-sequence processing > > semantics of %b should still remain available under the standard, > > under some other spelling, since relying on XSI echo is still not > > portable. > > > > One of the observations made in the meeting was that currently, both > > the POSIX spec for printf(1) as seen at [1], and the POSIX and C > > standard (including the upcoming C2x standard) for printf(3) as seen > > at [3] state that both the ' and # flag modifiers are currently > > undefined when applied to %s. > > Neither one is a very good choice, but `#' is the better one. It at least > has a passing resemblence to the desired functionality. Indeed, that's what the Austin Group settled on today after I first wrote my initial email, and what I wrote up in a patch to GNU Coreutils (https://debbugs.gnu.org/65659) > > Why not standardize another character, like %B? I suppose I'll have to look > at the etherpad for the discussion. I think that came up on the mailing > list, but I can't remember the details. Yes, https://austingroupbugs.net/view.php?id=1771 has a good discussion of the various ideas. %B is out for the same reason as %b: although the current C2x draft wording says that % is reserved for implementation use, other than [AEFGX] which already have a history of use by C (as it was, when C99 added %A, that caused problems for some folks), it goes on to _highly_ encourage any implementation that adds %b for "0b0" binary output also add %B for "0B0" binary output (to match the x/X dichotomy). Burning %B to retain the old behavior while repurposing %b to output lower-case binary values is thus a non-starter, while burning %#s (which C says is undefined) felt nicer. The Austin Group also felt that standardizing bash's behavior of %q/%Q for outputting quoted text, while too late for Issue 8, has a good chance of success, even though C says %q is reserved for standardization by C. Our reasoning there is that lots of libc over the years have used %qi as a synonym for %lli, and C would be foolish to burn %q for anything that does not match those semantics at the C language level; which means it will likely never be claimed by C and thus free for use by shell in the way that bash has already done. > > > Is there > > any interest in a patch to coreutils or bash that would add such a > > synonym, to make it easier to leave that functionality in place for > > POSIX Issue 9 even when %b is repurposed to align with C2x? > > It's maybe a two or three line change at most. Yeah, creating an alias proved to be pretty simple in coreutils; I spent more time documenting it than I did writing the code changes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: [PATCH] printf: add %#s alias to %b Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 20:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake , coreutils@gnu.org Cc: 65659@debbugs.gnu.org Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169351490913015 (code B ref 65659); Thu, 31 Aug 2023 20:49:02 +0000 Received: (at 65659) by debbugs.gnu.org; 31 Aug 2023 20:48:29 +0000 Received: from localhost ([127.0.0.1]:59338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qboaa-0003Np-ND for submit@debbugs.gnu.org; Thu, 31 Aug 2023 16:48:29 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:51228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qboaX-0003Mv-V5 for 65659@debbugs.gnu.org; Thu, 31 Aug 2023 16:48:26 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-401da71b7c5so13146925e9.2 for <65659@debbugs.gnu.org>; Thu, 31 Aug 2023 13:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693514891; x=1694119691; darn=debbugs.gnu.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=ayHQltCulUAh/O9svmJOrO6UVBHNGzGijWAQgiMNop0=; b=X05XaBXq42n0Z8g6akbq0sugpWSM+SybIW3ySBoQKh1PvjFwl8HDClbD66itNb32Z2 XPBr4Z6blcObEXQlIaDYLqRzloiAikIDh00S+6qaZDlUiSGSBz3+YJcfR9Wbv5a2iNoR Jj+lasLk/Qfv3R8aSQXqOBuQL2R0j01CKuRqIHOwbYe+9Fwt2UjIp3JBVBIDHGKqiQzH qN3jEzYWB0K8iuOsiYy8ZIOwWXq7ANOFzMY9LS3KDFdL9Op2W6wkyaDYFaL8B/aDgZUc K+qQLg5H4FIUHNArYTB4n7UZRHDCW6sIb1TnQ8jfgU1Nktkla3Q5JiG2T8RV1yNJ0yTX PAyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693514891; x=1694119691; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ayHQltCulUAh/O9svmJOrO6UVBHNGzGijWAQgiMNop0=; b=kNiN864xWd2SxKbnNXcTwVS+VG5LzhQ0RHka/ypbHxlTO2xDonkvu0jLUsjCXcYnGX 6XeolbHPUjjN8RMDYZrSObRX5y+LNOQQZkhGHSJ+0rIJrMVd0CKD/Duee51SwUdeYppq bWQRCXGY3S1MCcjnEG1/xqXaAmkSRz5BLjQ+3s48QsI9NtBmeL7fBkDH0s6zKDvfMyn8 icygmMqjFpOCTCzshTswn5LvTJ29+dioHe1ftESpKVkRfs3ga7zN9mG/Cni2Oinr/UYs z8+0NJIF6ip/MXZNXdTwUtU4/0hB0ksLxLMKH7Kq3J+ypND/YIY/CIS06SQMOqV3cNc3 annQ== X-Gm-Message-State: AOJu0Yx7p86yNwl9gp2PciOfrTdlrCR5gGHESths/2cXKWmMvf2EkR9E PM0LdANPXaa+2aP8SwKbwlA= X-Google-Smtp-Source: AGHT+IGeo+ngJ7E1t9aqz3LHPDRcKy0TSLP7+37E3gsI3b3jmQE3Pa21b7rLQFVqDtl39kNA3f8EYg== X-Received: by 2002:a05:600c:2283:b0:3ff:516b:5c65 with SMTP id 3-20020a05600c228300b003ff516b5c65mr318208wmf.30.1693514890944; Thu, 31 Aug 2023 13:48:10 -0700 (PDT) Received: from [192.168.1.20] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id p33-20020a05600c1da100b003fef5e76f2csm4851064wms.0.2023.08.31.13.48.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 13:48:10 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------90ZNzLREaQhkTH0fOm3lye9i" Message-ID: Date: Thu, 31 Aug 2023 21:48:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US References: <20230831183240.518692-1-eblake@redhat.com> From: =?UTF-8?Q?P=C3=A1draig?= Brady In-Reply-To: <20230831183240.518692-1-eblake@redhat.com> X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) This is a multi-part message in MIME format. --------------90ZNzLREaQhkTH0fOm3lye9i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 31/08/2023 19:31, Eric Blake wrote: > POSIX Issue 8 will be obsoleting %b (escape sequence interpolation) so > that future Issue 9 can change to having %b (binary literal output) > that aligns with C2x. But since escape interpolation may still remain > useful, POSIX suggested %#s (which is undefined in all versions of C) > as a possible alias for the older %b behavior. > > * src/printf.c (print_formatted, usage): Support %#s as an alias > for %b, in order to open doors to future repurposing of %b to > binary output while still allowing access to its old behavior. > * doc/coreutils.texi (printf invocation): Document it. > * NEWS: Likewise. > * tests/printf/printf-quote.sh: Add unit test coverage. Patch looks good thanks. I'd add in the attached test addition. As for compat, I notice that existing coreutils will reject %#s, while bash 5.2.15, ksh 1.0.4, dash 0.5.12 will treat as %s. cheers, Pádraig --------------90ZNzLREaQhkTH0fOm3lye9i Content-Type: text/x-patch; charset=UTF-8; name="printf-esc-test.patch" Content-Disposition: attachment; filename="printf-esc-test.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3Rlc3RzL3ByaW50Zi9wcmludGYuc2ggYi90ZXN0cy9wcmludGYvcHJp bnRmLnNoCmluZGV4IDgzNDAxMmNjNS4uMGMwOTQ4YzZjIDEwMDc1NQotLS0gYS90ZXN0cy9w cmludGYvcHJpbnRmLnNoCisrKyBiL3Rlc3RzL3ByaW50Zi9wcmludGYuc2gKQEAgLTY0LDYg KzY0LDggQEAgJHByb2cgJzYgXDQxXG4nIHwgdHIgJ1w0MScgJyEnID4+IG91dAogIyBwcmlu dHMgYSBOVUwgYnl0ZSBmb2xsb3dlZCBieSB0aGUgZGlnaXQgJzInIGFuZCBhICd5Jy4KICRw cm9nICc3IFwyeSBcMDJ5IFwwMDJ5IFwwMDAyeVxuJyB8dHIgJ1wwXDInICcqPScgPj4gb3V0 CiAKKyRwcm9nICc4ICUjcyAlI3MgJSNzICUjc1xuJyAnXDF5JyAnXDAxeScgJ1wwMDF5JyAn XDAwMDF5J3x0ciAnXDEnID0gPj4gb3V0CisjIERlcHJlY2F0ZWQgJWIgZXF1aXZhbGVudAog JHByb2cgJzggJWIgJWIgJWIgJWJcbicgJ1wxeScgJ1wwMXknICdcMDAxeScgJ1wwMDAxeSd8 dHIgJ1wxJyA9ID4+IG91dAogCiAkcHJvZyAnOSAlKmR4XG4nIC0yIDAgPj5vdXQgfHwgZmFp bD0xCkBAIC05MCw2ICs5Miw3IEBAIGNhdCA8PFxFT0YgPiBleHAKIDYgIQogNyA9eSA9eSA9 eSAqMnkKIDggPXkgPXkgPXkgPXkKKzggPXkgPXkgPXkgPXkKIDkgMCB4CiAxMCAweAogMTEg IHgK --------------90ZNzLREaQhkTH0fOm3lye9i-- From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Emanuele Torre Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 31 Aug 2023 21:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org, Chet Ramey Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169351631825306 (code B ref 65659); Thu, 31 Aug 2023 21:12:01 +0000 Received: (at 65659) by debbugs.gnu.org; 31 Aug 2023 21:11:58 +0000 Received: from localhost ([127.0.0.1]:59370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qboxK-0006a6-Da for submit@debbugs.gnu.org; Thu, 31 Aug 2023 17:11:58 -0400 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:53436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qboxI-0006Zt-RO for 65659@debbugs.gnu.org; Thu, 31 Aug 2023 17:11:57 -0400 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-31c479ede21so1092033f8f.2 for <65659@debbugs.gnu.org>; Thu, 31 Aug 2023 14:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693516302; x=1694121102; darn=debbugs.gnu.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=12J9bbCwjEHtoWp51yq1rzaqMZja62TuHFqZGRrc1wo=; b=ORlWCPfIeaVKZXVjxm0IG0z5yqooYM6WkHfyJRusnEA+zpBiC9nIM+xyjGdBfiAV6z byPLMJ+l5GSVleM4dIr3uYaw+fLV7M53U3u2IQClOZ+vr+4TxsgQ0y9+bGWwo4lKjNps IALyFsb5bDvFUtWOXr7zDbRCXS/7fum12g1Y9L7UdgnU91Z0T0a6Cw8poepSg01mDQ+l gYzzetCwLGMdJAn7q8oXVwNISOS2dJinnQ8Wdxex4Dk38Y9Ov/5B15bSQUIe2wcdJtx0 8j0erWsTwZS+tT1w9D/+hHuxDpMd2u1bzHzAE6DXSc+9/QfSuCiZlkjNETooLvuSGrP0 aAsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693516302; x=1694121102; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=12J9bbCwjEHtoWp51yq1rzaqMZja62TuHFqZGRrc1wo=; b=W23zT4hCsGKfgMns39gtyWr5+H8edZ0X8zP8sLVlyeROlvLMbRq23x/ZEf+fVAB7/u GMey53DP1Y9c73zcTYVgrxPwhDecVlMvXpoi0m14jEBRJ7OdCmpt85WZsYccF6lTN1Xt 7wzsDIACSnD4XpGVtqZmpQhgwqh53BnWqidDNVqFZgqxkgzKcC1E7VpkDz/DVoXojeWM 0SLG1eJQs/o9ZpsC96EltjdUFq4owWfiu3fhGbrAgODykajNFIFXhLl/KJtJY35FH/j7 Ta8EA3r9Nq2Lpb+KJjO2vN2UQeG4/90TpM9qW9w8t4UnOXlvJ6+kPcUT71fSun1CYGs9 Prsg== X-Gm-Message-State: AOJu0YzEkHNJY2kRz+Y0P97B70OsPmfE1rBpHGoNI7SwX/r7sRiG1TuE 4n0CHRO8SuO52yqc62rwfFM= X-Google-Smtp-Source: AGHT+IE6NdoCurSchiJkoq3x6MpmASdqEc4bEOBIyKlE8T0m/fyZwfCL8MoNiQSajgvNxPDiO65GFw== X-Received: by 2002:adf:ee92:0:b0:319:8b19:d5c8 with SMTP id b18-20020adfee92000000b003198b19d5c8mr514954wro.2.1693516301985; Thu, 31 Aug 2023 14:11:41 -0700 (PDT) Received: from t420 (net-93-70-31-151.cust.vodafonedsl.it. [93.70.31.151]) by smtp.gmail.com with ESMTPSA id n10-20020adffe0a000000b003140f47224csm3260477wrr.15.2023.08.31.14.11.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 14:11:41 -0700 (PDT) Date: Thu, 31 Aug 2023 23:11:39 +0200 From: Emanuele Torre Message-ID: References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> User-Agent: Mutt/2.2.11 (2023-08-18) X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Thu, Aug 31, 2023 at 03:02:22PM -0500, Eric Blake wrote: > On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote: > > Why not standardize another character, like %B? I suppose I'll have to look > > at the etherpad for the discussion. I think that came up on the mailing > > list, but I can't remember the details. > > Yes, https://austingroupbugs.net/view.php?id=1771 has a good > discussion of the various ideas. > > %B is out for the same reason as %b: although the current C2x draft > wording says that % is reserved for implementation use, other > than [AEFGX] which already have a history of use by C (as it was, when > C99 added %A, that caused problems for some folks), it goes on to > _highly_ encourage any implementation that adds %b for "0b0" binary > output also add %B for "0B0" binary output (to match the x/X > dichotomy). Burning %B to retain the old behavior while repurposing > %b to output lower-case binary values is thus a non-starter, while > burning %#s (which C says is undefined) felt nicer. Also note that, in ksh93, %B is already used for something else. It interprets its argument as a variable name, and dereferences it: `printf %B PWD' is similar to `printf %s "$PWD"' (assuming PWD is a string variable). o/ emanuele6 From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 06:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org X-Debbugs-Original-Cc: bug-coreutils@gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org Received: via spool by submit@debbugs.gnu.org id=B.169354884712837 (code B ref -1); Fri, 01 Sep 2023 06:15:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 06:14:07 +0000 Received: from localhost ([127.0.0.1]:59710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxPz-0003Ky-0c for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:14:07 -0400 Received: from lists.gnu.org ([2001:470:142::17]:48564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxPx-0003KM-2W for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:14:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbxPi-0004DL-1b; Fri, 01 Sep 2023 02:13:50 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbxPd-0006dA-4k; Fri, 01 Sep 2023 02:13:49 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 0E3B460004; Fri, 1 Sep 2023 06:13:36 +0000 (UTC) Date: Fri, 1 Sep 2023 07:13:36 +0100 From: Stephane Chazelas Message-ID: <20230901061336.mm5jx3e34ckovweo@chazelas.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GND-Sasl: stephane@chazelas.org Received-SPF: pass client-ip=217.70.183.195; envelope-from=stephane@chazelas.org; helo=relay3-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) 2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group: > In today's Austin Group call, we discussed the fact that printf(1) has > mandated behavior for %b (escape sequence processing similar to XSI > echo) that will eventually conflict with C2x's desire to introduce %b > to printf(3) (to produce 0b000... binary literals). [...] Is C2x's %b already set in stone? ksh93's printf (and I'd expect ast's standalone printf) has %[,[,]d to output a number in an arbitrary base which IMO seems like a better approach than introducing a new specifier for every base. $ printf '%..2d\n' 63 111111 $ printf '0b%.8.2d\n' 63 0b00111111 $ printf '%#.8.2d\n' 63 2#00111111 The one thing it can't do though is left-space-padding of 0b1111. printf %b is used in countless scripts especially the more correct/portable ones that use it to work around the portability fiasco that is echo's escape sequence expansion. I can't imagine it going away. Hard to imagine the C folks overlooked it, I'd expect printf %b to be known by any shell scripter. -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Phi Debian Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 06:31:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: chet.ramey@case.edu Cc: 65659@debbugs.gnu.org, eblake@redhat.com, bug-bash@gnu.org, austin-group-l@opengroup.org X-Debbugs-Original-Cc: bug-coreutils@gnu.org, Eric Blake , bug-bash@gnu.org, austin-group-l@opengroup.org Received: via spool by submit@debbugs.gnu.org id=B.169354983314466 (code B ref -1); Fri, 01 Sep 2023 06:31:04 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 06:30:33 +0000 Received: from localhost ([127.0.0.1]:59728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxfs-0003l9-SZ for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:30:33 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbvyO-0000j8-3B for submit@debbugs.gnu.org; Fri, 01 Sep 2023 00:41:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbvy4-0007Nr-96; Fri, 01 Sep 2023 00:41:13 -0400 Received: from mail-ua1-x933.google.com ([2607:f8b0:4864:20::933]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qbvy1-0003um-2k; Fri, 01 Sep 2023 00:41:10 -0400 Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-79a10807b4fso652636241.2; Thu, 31 Aug 2023 21:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693543266; x=1694148066; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VozFSbHCc217abZsK4KKT88QKgPyexm4gCpntWxZFWk=; b=GEwuMfqW955jxvTyKr7jiD1Pg7MXZWNr7sfyGGGBMppChoXwvkwOMuRaM/oRK1ihk0 fLEalGYrtMZmcc6wCMBeWJYQon9Y4qbWDGiKMW8N153kH2v4YcYt7WhbJRSMswvzBelF 6hwsFXMqRhWhwruDzhd1cTckveMmeQQvqJrQoPeNq6PKUMN0pT/UPFF5YJ7cs8S+OgUT F5Fu1NtjgBWlogiBKOJPuymqha6759ykbB4KoeerL8fgqGKn7fZTFybIYCmuwztzdN7x JecIC+MmT1AYllHhLj+v2iSM0GNwScbjFzDKEWrn1LTQEEYVwKpPoZAvGh9GukOUsAUZ Oj5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693543266; x=1694148066; h=cc: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=VozFSbHCc217abZsK4KKT88QKgPyexm4gCpntWxZFWk=; b=MilV089Lr50HikJbBRUZhkG9QMY2nm+1q6lUZ0uDlpRdUIUvMb7cRpPV5fSYE0MNrb 01IydPe7KpT8EK6m4rcA+Xndx3pSvowZ2QlHBvQIyzW8G3KR6aeKUUT+58BBTjP8jlz5 irUu1KE2b6i8MOMML3dbkg/GXPiZy9IootlXBQC4Z9u2UOc0qPslnKnhzWhc5XdLh2cr QzLvtXS72KX+5WPRFJMCHIKDRMu0oHr6+G/0iTAHxjLtYJOVa1dz2Um9wWvkV9UJR3se Dj98CAAKI0QaB/Fcd8iMdVWfU32bGfZu5ipLAv2vFWMo/1BDTaFRYhnWTIjET3fsXUqr 4aXQ== X-Gm-Message-State: AOJu0YyQgMKBxZfuoZ7jjf265YvnBHRS/FNwTPynLZedCqKlh9FKOviB CDgZdiLz8o10Zw/zlQLz2hrUpVbwcZxO0gt7hqI= X-Google-Smtp-Source: AGHT+IHjqotEF7dmsESCabJlqSo7R3OmTOGg+0rVpvlIEN8HtHn32j54kgF8kYE0r060PGjoe2VcRQFw/VqRsrrTh9w= X-Received: by 2002:a1f:ca03:0:b0:490:aa9b:4809 with SMTP id a3-20020a1fca03000000b00490aa9b4809mr1429506vkg.4.1693543266073; Thu, 31 Aug 2023 21:41:06 -0700 (PDT) MIME-Version: 1.0 References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> In-Reply-To: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> From: Phi Debian Date: Fri, 1 Sep 2023 06:40:54 +0200 Message-ID: Content-Type: multipart/alternative; boundary="000000000000c942cb060444c453" Received-SPF: pass client-ip=2607:f8b0:4864:20::933; envelope-from=phi.debian@gmail.com; helo=mail-ua1-x933.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Fri, 01 Sep 2023 02:30:25 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000c942cb060444c453 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 31, 2023 at 9:11=E2=80=AFPM Chet Ramey wr= ote: > > I doubt I'd ever remove %b, even in posix mode -- it's already been there > for 25 years. > > > Neither one is a very good choice, but `#' is the better one. It at least > has a passing resemblence to the desired functionality. > > Why not standardize another character, like %B? I suppose I'll have to lo= ok > at the etherpad for the discussion. I think that came up on the mailing > list, but I can't remember the details. > > Glad I red this thread before replying to the other one dealing with the same issue. I once worked on an issue on ksh93 regarding printf discrepency vs libc printf, and got replied that "ksh is not C". I Think we got to admit that shell's printf have departed from libc since long and now if a feature in libc appears and collide with printf(1) then we got to get yet another % exception char. In bash docco I see %b %q and %(datefmt...), so for a new feature we should get something that we think libc as little chance to target. My vote is for posix_printf %B mapping to libc_printf %b, with the idea that libc has little chance to have %B meaning UPPERCASE BINARY :-), as %x %X do. And yet one more line in the docco explaining this divergence. --000000000000c942cb060444c453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 31, 2023 at 9:11=E2=80=AF= PM Chet Ramey <chet.ramey@case.ed= u> wrote:

I doubt I'd ever remove %b, even in posix mode -- it's already been= there
for 25 years.


Neither one is a very good choice, but `#' is the better one. It at lea= st
has a passing resemblence to the desired functionality.

Why not standardize another character, like %B? I suppose I'll have to = look
at the etherpad for the discussion. I think that came up on the mailing
list, but I can't remember the details.


Glad I red this thread before replying= to the other one dealing with the same issue.

I o= nce worked on an issue on ksh93 regarding printf discrepency vs libc printf= , and got replied that "ksh is not C". I Think we got to admit th= at shell's printf have departed from libc since long and now if a featu= re in libc appears and collide with printf(1) then we got to get yet anothe= r % exception char. In bash docco I see %b %q and %(datefmt...), so for a n= ew feature we should get something that we think libc as little chance to t= arget.

My vote is for posix_printf %B mapping to l= ibc_printf %b, with the idea that libc has little chance to have %B meaning= UPPERCASE BINARY :-),=C2=A0 as %x %X do.

And = yet one more line in the docco explaining this divergence.


--000000000000c942cb060444c453-- From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Phi Debian Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 06:31:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: chet.ramey@case.edu Cc: 65659@debbugs.gnu.org, eblake@redhat.com, bug-bash@gnu.org, austin-group-l@opengroup.org X-Debbugs-Original-Cc: bug-coreutils@gnu.org, Eric Blake , bug-bash@gnu.org, austin-group-l@opengroup.org Received: via spool by submit@debbugs.gnu.org id=B.169354983414473 (code B ref -1); Fri, 01 Sep 2023 06:31:04 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 06:30:34 +0000 Received: from localhost ([127.0.0.1]:59730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxft-0003lH-SQ for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:30:34 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbwZe-0001tY-Rt for submit@debbugs.gnu.org; Fri, 01 Sep 2023 01:20:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbwZA-00044B-Kx; Fri, 01 Sep 2023 01:19:36 -0400 Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qbwZ5-0003P3-BG; Fri, 01 Sep 2023 01:19:30 -0400 Received: by mail-vs1-xe30.google.com with SMTP id ada2fe7eead31-44e8fc5dc63so708496137.2; Thu, 31 Aug 2023 22:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693545564; x=1694150364; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rS+xYT/Ufo3t3CH0VROUi6zVbn3UeIm9xaYR1tmYb7I=; b=GMFZrx9k+MwifrFIfgTykDJGa9/blS4SqlcBlCJN3TgCSKbUjCqQOcDwrW8lvrXV3d THBlO3bdqVDZqKNXUm6jFDe50yhvHwtydU8VJxBRl2VTObHh2m7H0PK3dQhbjMU8LgLy fJxNZ0iQPS5xah1HDM3fBU4BbQ9Wkq6/LwxtxiYNSGevLinS2RYUdpUPZ4FgRtwFmJ+o MCt5hdD1fFO9++3DsVEMaRC9MTRbifDdkXYfqWM5/ffEXuWlf7/8SaayT4gAGQGZ5yGT TVQ9HG72tIIOgXMKSR4tQN/b3LZnE7jQvqmYKElW7ymO+jq7ADSZi+etOeenCeoFHXI8 Ro4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693545564; x=1694150364; h=cc: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=rS+xYT/Ufo3t3CH0VROUi6zVbn3UeIm9xaYR1tmYb7I=; b=Ebej0TiFimRvf4EN8y2/4Ko7gX219vOcT2xXfLkGTY6SYTr+RDIVV7igq/eFS2ru0y EcHg8m9p+YJO+pzlpvQX8bPcYPcEn6B0C/cLrIdrxiX+cG0Zmqb7WJ+IJEXYPmX91I/H 1VrOPAEiguCoKm2f4kU80yr+N4EdYNBXNrJe2xffrqfO/2m71W/rr+ilycNnp1ufin0B AKxQCpEZRCQ4HZKDRxtW+2YHIdvboPu4TH9TU1Zgw9iySFeJnHvQapzgi4UytKjPR1Gv 26oSyfy4K+KUQOLLqSszIkY5PRhjeSz8cgl6pk9CBaLAwFbSR14Qq6oGe+nMCwFMx7hn R+Jw== X-Gm-Message-State: AOJu0YxctIIUHAFmTrHnpa0QkR5V0JoalQem4JvX2yhb9Qwh6GjgL3Ue X2JQ5TortvFoxtSL8XPfwlEDthZs48LnzQ3xSGg= X-Google-Smtp-Source: AGHT+IFCi67/IM+T6CTKoPg2lAuoNCC6EgEn/YVju2SPdezfk4NY8kpGBeWU++eOs9kLUC27DlzOMwYZAzp3DubD+aE= X-Received: by 2002:a67:efd6:0:b0:445:202:d278 with SMTP id s22-20020a67efd6000000b004450202d278mr1565000vsp.32.1693545564450; Thu, 31 Aug 2023 22:19:24 -0700 (PDT) MIME-Version: 1.0 References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> In-Reply-To: From: Phi Debian Date: Fri, 1 Sep 2023 07:19:13 +0200 Message-ID: Content-Type: multipart/alternative; boundary="000000000000c7b2d00604454d2a" Received-SPF: pass client-ip=2607:f8b0:4864:20::e30; envelope-from=phi.debian@gmail.com; helo=mail-vs1-xe30.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Fri, 01 Sep 2023 02:30:26 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000c7b2d00604454d2a Content-Type: text/plain; charset="UTF-8" Well after reading yet another thread regarding libc_printf() I got to admit that even %B is crossed out, (Yet already choosen by ksh93) The other thread also speak about libc_printf() documentting %# as undefined for things other than a, A, e, E, f, F, g, and G, yet the same thread also talk about a A comming late (citing C99) in the dance, meaning what is undefined today become defined tomorow, so %#b is no safer. My guess is that printf(1) is now doomed to follow its route, keep its old format exception, and then may be implement something like c_printf like printf but the format string follow libc semantic, or may be a -C option to printf(1)... Well in all case %b can not change semantic in the bash script, since it is there for so long, even if it depart from python, perl, libc, it is unfortunate but that's the way it is, nobody want a semantic change, and on next routers update, see the all internet falling appart :-) --000000000000c7b2d00604454d2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well after reading yet another thread regarding libc_= printf() I got to admit that even %B is crossed out, (Yet already choosen b= y ksh93)

The other thread also speak about lib= c_printf() documentting %# as undefined for things other than=C2=A0 a, A, e= , E, f, F, g, and G, yet the same thread also talk about a A comming late (= citing C99) in the dance, meaning what is undefined today become defined to= morow, so %#b is no safer.

My guess is that printf= (1) is now doomed to follow its route, keep its old format exception, and t= hen may be implement something like c_printf like printf but the format str= ing follow libc semantic, or may be a -C option to printf(1)...

Well in all case %b can not change semantic in the bash s= cript, since it is there for so long, even if it depart from python, perl, = libc, it is unfortunate but that's the way it is, nobody want a semanti= c change, and on next routers update, see the all internet falling appart := -)

--000000000000c7b2d00604454d2a-- From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 06:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: eblake@redhat.com, 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org X-Debbugs-Original-To: Eric Blake , bug-coreutils@gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org Received: via spool by submit@debbugs.gnu.org id=B.169355059015675 (code B ref -1); Fri, 01 Sep 2023 06:44:01 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 06:43:10 +0000 Received: from localhost ([127.0.0.1]:59751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxs6-00044k-CW for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:43:10 -0400 Received: from lists.gnu.org ([2001:470:142::17]:58910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxs3-00044X-W4 for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:43:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbxrp-0006FR-At; Fri, 01 Sep 2023 02:42:53 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbxrm-0005JD-Rz; Fri, 01 Sep 2023 02:42:53 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 8E07AC0008; Fri, 1 Sep 2023 06:42:46 +0000 (UTC) Date: Fri, 1 Sep 2023 07:42:45 +0100 From: Stephane Chazelas Message-ID: <20230901064245.3ue3dudk6u7x3ipj@chazelas.org> References: <20230901061336.mm5jx3e34ckovweo@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230901061336.mm5jx3e34ckovweo@chazelas.org> X-GND-Sasl: stephane@chazelas.org Received-SPF: pass client-ip=2001:4b98:dc4:8::226; envelope-from=stephane@chazelas.org; helo=relay6-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) 2023-09-01 07:13:36 +0100, Stephane Chazelas via austin-group-l at The Open Group: > 2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group: > > In today's Austin Group call, we discussed the fact that printf(1) has > > mandated behavior for %b (escape sequence processing similar to XSI > > echo) that will eventually conflict with C2x's desire to introduce %b > > to printf(3) (to produce 0b000... binary literals). > [...] > > Is C2x's %b already set in stone? > > ksh93's printf (and I'd expect ast's standalone printf) has > %[,[,]d to output a number in an > arbitrary base which IMO seems like a better approach than > introducing a new specifier for every base. [...] For completeness, several shells also support expanding integers in arbitrary bases. Like ksh's typeset -i2 binary=123 already there in ksh85, possibly earlier, also available in pdksh and derivatives and zsh. Originally with the base number not specified the output base was derived from the first assignment like typeset -i var; var='2#111' would get you a $var that expands in binary. Looks like that was discontinued in ksh93, but it's still there in mksh or zsh. And there's also: $ echo $(( [#2] 16 )) $(( [##2] 16 )) 2#10000 10000 In zsh (note that you don't get 0b10000 upon $(( [#2] 16 )) after set -o cbases). If bash added: printf -v var %..2 16 à la ksh93, that would bridge that gap. How to output/expand numbers in bases other thn 8, 10, 16 is a recurring question for bash, with people generally surprised that it can *input* numbers in any base, but not *output* in any base. See https://unix.stackexchange.com/questions/415077/how-to-add-two-hexadecimal-numbers-in-a-bash-script/415107#415107 https://unix.stackexchange.com/questions/616215/bash-arithmetic-outputs-result-in-decimal https://unix.stackexchange.com/questions/749988/arbitrary-base-conversion-from-base-10-using-only-builtins-in-bash to list only a few. -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: =?UTF-8?Q?O=C4=9Fuz?= Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 06:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Phi Debian Cc: 65659@debbugs.gnu.org, eblake@redhat.com, bug-bash@gnu.org, austin-group-l@opengroup.org, chet.ramey@case.edu X-Debbugs-Original-Cc: bug-coreutils@gnu.org, Eric Blake , bug-bash@gnu.org, austin-group-l@opengroup.org, chet.ramey@case.edu Received: via spool by submit@debbugs.gnu.org id=B.169355065215782 (code B ref -1); Fri, 01 Sep 2023 06:45:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 06:44:12 +0000 Received: from localhost ([127.0.0.1]:59755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxt5-00046U-U5 for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:44:12 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45200) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbxt4-00046I-Hl for submit@debbugs.gnu.org; Fri, 01 Sep 2023 02:44:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbxsq-0006fH-1M; Fri, 01 Sep 2023 02:43:56 -0400 Received: from mail-il1-x131.google.com ([2607:f8b0:4864:20::131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qbxso-0005T3-18; Fri, 01 Sep 2023 02:43:55 -0400 Received: by mail-il1-x131.google.com with SMTP id e9e14a558f8ab-34bae82b2ffso4932435ab.1; Thu, 31 Aug 2023 23:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693550632; x=1694155432; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V1ekzRpZuFjaSYy5RLrgqUkJsY3azQJlw0YLTyhIjXw=; b=EHG7iAH4IgZK5twc/oufi3rp4GNsOmelGkIqHdedGglttcbYV9168TENN8hH4O/gJ0 UX6SuFzmWOTUX6A7V6hVjEm7ThasCP/Pj8D/ZH25V2B0Xw+L5cm3csvRgc+RTiEH2gWf xB1t7mmIW4NhGTrvHmqOovlGhTDDu1qRVtdvJ0Nl6xbcrBfV8zmYoEvj3szzYwLJuDer 8KpWYjUsw1vVLm3O9v/OzyWoxfl1odwwjZlfYlMYLYP9TGkeJiLh9OqaUborw9Z6lGUQ GzuzPfudGYlfLmYeh9VwdO1Zot/eT/PG8Cdem1Ziaka9WAhSKJ5TgQjqHCxsO6UBvpE8 vX5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693550632; x=1694155432; h=content-transfer-encoding:cc: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=V1ekzRpZuFjaSYy5RLrgqUkJsY3azQJlw0YLTyhIjXw=; b=Vnka61y5Sjq3EgafNqsf3BMf4BTxrF9T3dsGaeIjqyZXh+XBIBj6sNHBdE+YNnRV+X qFWiwqnSbOrOHAFr8293HUjODFRrmwextOLpfkOZ/mgunhjyLfVEhrHQ5/yDHD2NeGsO L3Bs5A7G8Fn/u5Z1gYMEWu1HGR5zclkNW+1a5YqbXOgYdHBrycF4z638yBusNW6wKGmT NT+kbh4Abtn/mAegMzl1QfezyvaLfrVsDe1sNvWzbWQzpxWaZV+dBzQeAyrTeb3j9WRM hEqjRdlO5Ob6WcqRRbo44xEIb5PVrmUUq+pNHlSOiMbVl8vRuCqEw0Hol8yGy2IZMW04 fkjA== X-Gm-Message-State: AOJu0YyZfDxmB8x412YhmFVXdUPQ3uE9R77datRUdPGyTLb2lkBoQYFZ atMZV2AAzhuP8HBopMah7I4T+oUPoNPPmVDredc= X-Google-Smtp-Source: AGHT+IHt5iLG7FAT29b5tTHubahQ4eQSnGTipBp6/kKiPgHxSkGSzZiZyRq8y9ktYozSEWDsKIZ85Z3jr71UpOU+x1w= X-Received: by 2002:a05:6e02:d42:b0:349:8811:fc51 with SMTP id h2-20020a056e020d4200b003498811fc51mr1641176ilj.20.1693550632170; Thu, 31 Aug 2023 23:43:52 -0700 (PDT) MIME-Version: 1.0 References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> In-Reply-To: From: =?UTF-8?Q?O=C4=9Fuz?= Date: Fri, 1 Sep 2023 09:44:08 +0300 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::131; envelope-from=oguzismailuysal@gmail.com; helo=mail-il1-x131.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Fri, Sep 1, 2023 at 7:41=E2=80=AFAM Phi Debian wr= ote: > My vote is for posix_printf %B mapping to libc_printf %b In the shell we already have bc for base conversion. Does POSIX really have to support C2x %b in the first place? From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 07:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?O=C4=9Fuz?= Cc: chet.ramey@case.edu, 65659@debbugs.gnu.org, austin-group-l@opengroup.org, phi.debian@gmail.com, bug-bash@gnu.org, eblake@redhat.com X-Debbugs-Original-Cc: chet.ramey@case.edu, bug-coreutils@gnu.org, austin-group-l@opengroup.org, Phi Debian , bug-bash@gnu.org, Eric Blake Received: via spool by submit@debbugs.gnu.org id=B.169355238018719 (code B ref -1); Fri, 01 Sep 2023 07:13:01 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 07:13:00 +0000 Received: from localhost ([127.0.0.1]:59778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbyKy-0004rr-Gq for submit@debbugs.gnu.org; Fri, 01 Sep 2023 03:13:00 -0400 Received: from lists.gnu.org ([2001:470:142::17]:38596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbyKx-0004rd-9e for submit@debbugs.gnu.org; Fri, 01 Sep 2023 03:12:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbyKh-0000UN-2n; Fri, 01 Sep 2023 03:12:44 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbyKd-00046C-PB; Fri, 01 Sep 2023 03:12:42 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 10F7960003; Fri, 1 Sep 2023 07:12:33 +0000 (UTC) Date: Fri, 1 Sep 2023 08:12:33 +0100 From: Stephane Chazelas Message-ID: <20230901071233.s3dtjsi57ezc2o6d@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-GND-Sasl: stephane@chazelas.org Received-SPF: pass client-ip=2001:4b98:dc4:8::223; envelope-from=stephane@chazelas.org; helo=relay3-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) 2023-09-01 09:44:08 +0300, OÄŸuz via austin-group-l at The Open Group: > On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote: > > My vote is for posix_printf %B mapping to libc_printf %b > > In the shell we already have bc for base conversion. Does POSIX really > have to support C2x %b in the first place? Yes, though note: - that implies forking a process and loading an external executable and its libraries - bc is not always available. It's not installed by default on Debian for instance. - for bases over 16, it uses some unusual representation that can't be used anywhere. A summary of some options for some common POSIX-like shells at https://unix.stackexchange.com/questions/191205/bash-base-conversion-from-decimal-to-hex/191209#191209 -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 08:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org, Chet Ramey Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169355518023252 (code B ref 65659); Fri, 01 Sep 2023 08:00:02 +0000 Received: (at 65659) by debbugs.gnu.org; 1 Sep 2023 07:59:40 +0000 Received: from localhost ([127.0.0.1]:59789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbz47-00062y-JI for submit@debbugs.gnu.org; Fri, 01 Sep 2023 03:59:39 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:50825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbz44-00062i-Gj for 65659@debbugs.gnu.org; Fri, 01 Sep 2023 03:59:38 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3EB04C0009; Fri, 1 Sep 2023 07:59:20 +0000 (UTC) Date: Fri, 1 Sep 2023 08:59:19 +0100 From: Stephane Chazelas Message-ID: <20230901075919.fhbkhnop4xiblas4@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> X-GND-Sasl: stephane@chazelas.org X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group: [...] > The current POSIX says that %b was added so that on a non-XSI > system, you could do: > > my_echo() { > printf %b\\n "$*" > } That is dependant on the current value of $IFS. You'd need: xsi_echo() ( IFS=' ' printf '%b\n' "$*" ) Or the other alternatives listed at https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/65819#65819 [...] > Bash already has shopt -s xpg_echo Note that in bash, you need both shopt -s xpg_echo set -o posix To get a XSI echo. Without the latter, options are still recognised. You can get a XSI echo without those options with: xsi_echo() { local IFS=' ' - set +o posix echo -e "$*\n\c" } The addition of those \n\c (noop) avoids arguments being treated as options if they start with -. [...] > The Austin Group also felt that standardizing bash's behavior of %q/%Q > for outputting quoted text, while too late for Issue 8, has a good > chance of success, even though C says %q is reserved for > standardization by C. Our reasoning there is that lots of libc over > the years have used %qi as a synonym for %lli, and C would be foolish > to burn %q for anything that does not match those semantics at the C > language level; which means it will likely never be claimed by C and > thus free for use by shell in the way that bash has already done. [...] Note that %q is from ksh93, not bash and is not portable across implementations and with most including bash's gives an output that is not safe for reinput in arbitrary locales (as it uses $'...' in some cases), not sure it's a good idea to add it to the standard, or at least it should come with fat warnings about the risk in using it. See also: https://unix.stackexchange.com/questions/379181/escape-a-variable-for-use-as-content-of-another-script/600214#600214 -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Stephane Chazelas Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org, Chet Ramey Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169357053532699 (code B ref 65659); Fri, 01 Sep 2023 12:16:02 +0000 Received: (at 65659) by debbugs.gnu.org; 1 Sep 2023 12:15:35 +0000 Received: from localhost ([127.0.0.1]:59997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc33m-0008TF-OD for submit@debbugs.gnu.org; Fri, 01 Sep 2023 08:15:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:51124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc33l-0008Ns-4e for 65659@debbugs.gnu.org; Fri, 01 Sep 2023 08:15:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693570523; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HMoSbv82IMDL/nlYVUjJAL0WkjBVSZIttUpectSWWBA=; b=O1W5jLw/o2UEOdCFx11bQWZwlGS0SpUemIp+Ww0+V62tCqk3zrUEkCUgG5dZDGJABFfhvo Ef9CFbOsDi76KDkTDAa04weGupQuVAdKMpZJbdXOZnVKswSH/eA9zLlo/gxh8PaVlRjXlm QS51w9tpxj9kYen1xRK7SLa1jxmj7ws= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-483-PfQ5QT4bOpOb61-0kRh1-w-1; Fri, 01 Sep 2023 08:15:18 -0400 X-MC-Unique: PfQ5QT4bOpOb61-0kRh1-w-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B124229AB3E1; Fri, 1 Sep 2023 12:15:17 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E15E493110; Fri, 1 Sep 2023 12:15:16 +0000 (UTC) Date: Fri, 1 Sep 2023 07:15:14 -0500 From: Eric Blake Message-ID: References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> <20230901075919.fhbkhnop4xiblas4@chazelas.org> MIME-Version: 1.0 In-Reply-To: <20230901075919.fhbkhnop4xiblas4@chazelas.org> User-Agent: NeoMutt/20230517 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote: > 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group: > [...] > > The current POSIX says that %b was added so that on a non-XSI > > system, you could do: > > > > my_echo() { > > printf %b\\n "$*" > > } > > That is dependant on the current value of $IFS. You'd need: > > xsi_echo() ( > IFS=' ' > printf '%b\n' "$*" > ) Let's read the standard in context (Issue 8 draft 3 page 2793 line 92595): " The printf utility can be used portably to emulate any of the traditional behaviors of the echo utility as follows (assuming that IFS has its standard value or is unset): • The historic System V echo and the requirements on XSI implementations in this volume of POSIX.1-202x are equivalent to: printf "%b\n" "$*" " So yes, the standard does mention the requirement to have a sane IFS, and I failed to include that in my one-off implementation of my_echo(). Thank you for pointing out a more robust version. > > Or the other alternatives listed at > https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/65819#65819 > > [...] > > Bash already has shopt -s xpg_echo > > Note that in bash, you need both > > shopt -s xpg_echo > set -o posix > > To get a XSI echo. Without the latter, options are still > recognised. You can get a XSI echo without those options with: > > xsi_echo() { > local IFS=' ' - > set +o posix > echo -e "$*\n\c" > } > > The addition of those \n\c (noop) avoids arguments being treated as > options if they start with -. As an extension, Bash (and Coreutils) happen to honor \c always, and not just for %b. But POSIX only requires \c handling for %b. And while Issue 8 has taken steps to allow implementations to support 'echo -e', it is still not standardized behavior; so your xsi_echo() is bash-specific (which is not necessarily a problem, as long as you are aware it is not portable). > [...] > > The Austin Group also felt that standardizing bash's behavior of %q/%Q > > for outputting quoted text, while too late for Issue 8, has a good > > chance of success, even though C says %q is reserved for > > standardization by C. Our reasoning there is that lots of libc over > > the years have used %qi as a synonym for %lli, and C would be foolish > > to burn %q for anything that does not match those semantics at the C > > language level; which means it will likely never be claimed by C and > > thus free for use by shell in the way that bash has already done. > [...] > > Note that %q is from ksh93, not bash and is not portable across > implementations and with most including bash's gives an output > that is not safe for reinput in arbitrary locales (as it uses > $'...' in some cases), not sure it's a good idea to add it to > the standard, or at least it should come with fat warnings about > the risk in using it. %q is NOT being added to Issue 8, but $'...' is. Bug 1771 asked if %q could be added to Issue 8, but it came it past the deadline for feature requests, so the best we could do is add a FUTURE DIRECTIONS blurb that mentions the idea. But since FUTURE DIRECTIONS is non-normative, we can always change our mind in Issue 9 and delete that text if it turns out we can't get consensus to standardize some form of %q/%Q after all. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 12:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Phi Debian Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org, chet.ramey@case.edu Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.16935728638344 (code B ref 65659); Fri, 01 Sep 2023 12:55:01 +0000 Received: (at 65659) by debbugs.gnu.org; 1 Sep 2023 12:54:23 +0000 Received: from localhost ([127.0.0.1]:60059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc3fK-0002AW-TP for submit@debbugs.gnu.org; Fri, 01 Sep 2023 08:54:23 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:32497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc3fI-0002AO-PD for 65659@debbugs.gnu.org; Fri, 01 Sep 2023 08:54:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693572851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BweqTaGZM/J91e+JOCZLdi9uIWUviw8FWTuOrE3+UjQ=; b=IRIDDroO9mCG5HhbntE5GVYmQmS1IsI/OyVFVCYUZcXA0LDKvzj+cQokFr2FiK1mxesZ/B plDZu3GjGrCEoDUXtKW8OXX0CbwiQfuHwfFW/pVpw+N7kC4FbrCENHOYVJTWe0E6lGKhRh gZ5poqWuotbLNUD7npA9ERjQO3h/MpA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-522-vwD_V3NTMn2jFX0ZZFIUOQ-1; Fri, 01 Sep 2023 08:54:06 -0400 X-MC-Unique: vwD_V3NTMn2jFX0ZZFIUOQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A09BD800193; Fri, 1 Sep 2023 12:54:05 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 89E4349310F; Fri, 1 Sep 2023 12:54:04 +0000 (UTC) Date: Fri, 1 Sep 2023 07:54:02 -0500 From: Eric Blake Message-ID: References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20230517 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Sep 01, 2023 at 07:19:13AM +0200, Phi Debian wrote: > Well after reading yet another thread regarding libc_printf() I got to > admit that even %B is crossed out, (Yet already choosen by ksh93) > > The other thread also speak about libc_printf() documentting %# as > undefined for things other than a, A, e, E, f, F, g, and G, yet the same > thread also talk about a A comming late (citing C99) in the dance, meaning > what is undefined today become defined tomorow, so %#b is no safer. > Caution: The proposal here is for %#s (an alternative string), not %#b (which C2x wants to be similar to %#x, in that it outputs a '0b' prefix for all values except bare '0'). Yes, there is a slight risk that C may decide to define %#s. But as the Austin Group includes a member of WG14, we are able to advise the C committee that such an addition is not wise. > My guess is that printf(1) is now doomed to follow its route, keep its old > format exception, and then may be implement something like c_printf like > printf but the format string follow libc semantic, or may be a -C option to > printf(1)... Adding an option to printf is also a possibility, if there is wide-spread implementation practice to standardize. If someone wants to implement 'printf -C' right now, that could help feed such a future standardization. But it is somewhat orthogonal to the request in this thread, which is how to allow users to still access the old %b behavior even if %b gets repurposed in the future; if we can get multiple implementations to add a %#s alias now, it makes the future decisions easier (even if it is too late for Issue 8 to add any new features, or for that matter, to make any normative changes other than marking %b obsolescent as a way to be able to revisit it in the future for Issue 9). > > Well in all case %b can not change semantic in the bash script, since it is > there for so long, even if it depart from python, perl, libc, it is > unfortunate but that's the way it is, nobody want a semantic change, and on > next routers update, see the all internet falling appart :-) How many scripts in the wild actually use %b, though? And if there are such scripts, anything we can do to make it easy to do a drop-in replacement that still preserves the old behavior (such as changing %b to %#s) is going to be easier to audit than the only other currently-portable alternative of actually analyzing the string to see if it uses any octal or \c escapes that have to be re-written to portably function as a printf format argument. POSIX is not mandating %#s at this time, so much as suggesting that if implementations are willing to implement it now, it will make Issue 9 easier to reason about. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 15:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org, Chet Ramey Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169358233623697 (code B ref 65659); Fri, 01 Sep 2023 15:33:01 +0000 Received: (at 65659) by debbugs.gnu.org; 1 Sep 2023 15:32:16 +0000 Received: from localhost ([127.0.0.1]:33688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc687-0006A8-Ks for submit@debbugs.gnu.org; Fri, 01 Sep 2023 11:32:15 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]:51721) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc686-00069t-67 for 65659@debbugs.gnu.org; Fri, 01 Sep 2023 11:32:14 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2441AC0004; Fri, 1 Sep 2023 15:31:55 +0000 (UTC) Date: Fri, 1 Sep 2023 16:31:55 +0100 From: Stephane Chazelas Message-ID: <20230901153155.rbkeiumcne2qdspa@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <7fjrtjxqdw45ceik4syafvdn2jx3bhvta4ejics2bzvdrfdm5p@yadvx2qfh42s> <20230901075919.fhbkhnop4xiblas4@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GND-Sasl: stephane@chazelas.org X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 2023-09-01 07:15:14 -0500, Eric Blake: [...] > > Note that in bash, you need both > > > > shopt -s xpg_echo > > set -o posix > > > > To get a XSI echo. Without the latter, options are still > > recognised. You can get a XSI echo without those options with: > > > > xsi_echo() { > > local IFS=' ' - > > set +o posix > > echo -e "$*\n\c" > > } > > > > The addition of those \n\c (noop) avoids arguments being treated as > > options if they start with -. > > As an extension, Bash (and Coreutils) happen to honor \c always, and > not just for %b. But POSIX only requires \c handling for %b. > > And while Issue 8 has taken steps to allow implementations to support > 'echo -e', it is still not standardized behavior; so your xsi_echo() > is bash-specific (which is not necessarily a problem, as long as you > are aware it is not portable). [...] Yes, none of local (from ash I believe), the posix option (several shells have an option called posix all used to improve POSIX conformance, bash may have been the first) nor -e (from Research Unix v8) are standard, that part was about bash specifically (as the thread is also posted on gnu.bash.bug). BTW, that xsi_echo is not strictly equivalent to a XSI echo in the case where the last character of the last argument is an unescaped backslash or a character whose encoding ends in the same byte as the encoding of backslash. -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Martin D Kealey Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 17:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org X-Debbugs-Original-Cc: bug-coreutils@gnu.org, bug-bash , austin-group-l@opengroup.org Received: via spool by submit@debbugs.gnu.org id=B.16935897253678 (code B ref -1); Fri, 01 Sep 2023 17:36:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2023 17:35:25 +0000 Received: from localhost ([127.0.0.1]:33808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc83E-0000x4-Fl for submit@debbugs.gnu.org; Fri, 01 Sep 2023 13:35:24 -0400 Received: from lists.gnu.org ([2001:470:142::17]:38984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc65m-00064X-HP for submit@debbugs.gnu.org; Fri, 01 Sep 2023 11:29:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc65X-0007TS-EZ; Fri, 01 Sep 2023 11:29:35 -0400 Received: from shaun.sig.nz ([103.6.212.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc65O-0001Fs-6w; Fri, 01 Sep 2023 11:29:35 -0400 Received: from kohi.sig.nz ([114.23.207.132] helo=u1.kohi.sig.nz) by shaun.sig.nz ([103.6.212.24]:587) with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92 #5) id 1qc65A-0001ag-2R ; Fri, 01 Sep 2023 15:29:12 +0000 Received: from mail-yb1-f169.google.com ([209.85.219.169]) by u1.kohi.sig.nz ([192.168.2.103]:587) with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1 #4) id 1qc659-0002FP-Sh ; Sat, 02 Sep 2023 03:29:11 +1200 Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-d7e387c33f3so1610005276.1; Fri, 01 Sep 2023 08:29:11 -0700 (PDT) X-Gm-Message-State: AOJu0YwujFAKinxUe6ujy13C9cCOw6bDrzxO+9brlPyxawmrc1Xv4obJ uxaWFCaiLy17rvLwEx6zaGAoAQV+qgcrpC4w7dw= X-Google-Smtp-Source: AGHT+IE6h3nLCzCiCYsHj9B0KXTRwN+n+wtaa82pyJpgvY5iCnGS5ITtD4lQe9nsUOVjOJrECSeI1ZTum3X7B9ah19c= X-Received: by 2002:a25:bcc3:0:b0:d78:441d:4d62 with SMTP id l3-20020a25bcc3000000b00d78441d4d62mr2892190ybm.22.1693582148962; Fri, 01 Sep 2023 08:29:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin D Kealey Date: Sat, 2 Sep 2023 01:28:55 +1000 X-Gmail-Original-Message-ID: Message-ID: Content-Type: multipart/alternative; boundary="00000000000063120706044dd280" Received-SPF: pass client-ip=103.6.212.24; envelope-from=martin@kurahaupo.gen.nz; helo=shaun.sig.nz X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Mailman-Approved-At: Fri, 01 Sep 2023 13:35:17 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000063120706044dd280 Content-Type: text/plain; charset="UTF-8" If compatibility with C is really that important, shouldn't we be fixing %c? Its current behaviour as a synonym for %.1s doesn't provide significant utility, and arguably differs from C's "take an int and output the corresponding single byte", not "take the first byte of a string and output that". Whilst I wouldn't object to adding %#s (or %#b for that matter), I'm uncomfortable about changing existing behaviour, especially when it's just for the sake of linguistic simplicity in the standard.) Plenty of projects have functions that accept a format string and pass it through to printf (sometimes with names like warnf, errorf, panicf); it would be non trivial to locate indirect format string parameters. An estimate of "a few years" is WAY short of the timeframe needed to weed out old usage; embedded devices typically run the same version of bash from the time they leave the factory until they reach the scrap disassembly plant (or landfill) a decade or more later. One of the benefits of printf over echo is that there aren't two mutually incompatible ways of interpreting the data; this would take us back to the bad old days of having to dynamically select the format string depending on which version of the Shell the script is running under. Please no. -Martin On Fri, 1 Sept 2023 at 01:35, Eric Blake wrote: > In today's Austin Group call, we discussed the fact that printf(1) has > mandated behavior for %b (escape sequence processing similar to XSI > echo) that will eventually conflict with C2x's desire to introduce %b > to printf(3) (to produce 0b000... binary literals). > > For POSIX Issue 8, we plan to mark the current semantics of %b in > printf(1) as obsolescent (it would continue to work, because Issue 8 > targets C17 where there is no conflict with C2x), but with a Future > Directions note that for Issue 9, we could remove %b entirely, or > (more likely) make %b output binary literals just like C. But that > raises the question of whether the escape-sequence processing > semantics of %b should still remain available under the standard, > under some other spelling, since relying on XSI echo is still not > portable. > > One of the observations made in the meeting was that currently, both > the POSIX spec for printf(1) as seen at [1], and the POSIX and C > standard (including the upcoming C2x standard) for printf(3) as seen > at [3] state that both the ' and # flag modifiers are currently > undefined when applied to %s. > > [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html > "The format operand shall be used as the format string described in > XBD File Format Notation[2] with the following exceptions:..." > > [2] > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05 > "The flag characters and their meanings are: ... > # The value shall be converted to an alternative form. For c, d, i, u, > and s conversion specifiers, the behavior is undefined. > [and no mention of ']" > > [3] https://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html > "The flag characters and their meanings are: > ' [CX] [Option Start] (The .) The integer portion of the > result of a decimal conversion ( %i, %d, %u, %f, %F, %g, or %G ) > shall be formatted with thousands' grouping characters. For other > conversions the behavior is undefined. The non-monetary grouping > character is used. [Option End] > ... > # Specifies that the value is to be converted to an alternative > form. For o conversion, it shall increase the precision, if and only > if necessary, to force the first digit of the result to be a zero > (if the value and precision are both 0, a single 0 is printed). For > x or X conversion specifiers, a non-zero result shall have 0x (or > 0X) prefixed to it. For a, A, e, E, f, F, g, and G conversion > specifiers, the result shall always contain a radix character, even > if no digits follow the radix character. Without this flag, a radix > character appears in the result of these conversions only if a digit > follows it. For g and G conversion specifiers, trailing zeros shall > not be removed from the result as they normally are. For other > conversion specifiers, the behavior is undefined." > > Thus, it appears that both %#s and %'s are available for use for > future standardization. Typing-wise, %#s as a synonym for %b is > probably going to be easier (less shell escaping needed). Is there > any interest in a patch to coreutils or bash that would add such a > synonym, to make it easier to leave that functionality in place for > POSIX Issue 9 even when %b is repurposed to align with C2x? > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. > Virtualization: qemu.org | libguestfs.org > > > --00000000000063120706044dd280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<devils_advocate>If compatibi= lity with C is really that important, shouldn't we be fixing %c? Its cu= rrent behaviour as a synonym for %.1s doesn't provide significant util= ity, and arguably differs from C's "take an int and output the cor= responding single byte", not "take the first byte of a string and= output that".
</devils_advocate>

Whilst I wouldn't object to adding %#s (or %#b for th= at matter), I'm uncomfortable about changing existing behaviour, especi= ally when it's just for the sake of linguistic simplicity in the standa= rd.)

Plenty of projects have functions that accept= a format string and pass it through to printf (sometimes with names like w= arnf, errorf, panicf); it would be non trivial to locate indirect format st= ring parameters. An estimate of "a few years" is WAY short of the= timeframe needed to weed out old usage; embedded devices typically run the= same version of bash from the time they leave the factory until they reach= the scrap disassembly plant (or landfill) a decade or more later.

One of the benefits of printf ov= er echo is that there aren't two mutually incompatible ways of interpre= ting the data; this would take us back to the bad old days of having to dyn= amically select the format string depending on which version of the Shell t= he script is running under.

Please no.

-Martin= =C2=A0

On Fri, 1 Sept 2023 at 01:35, Eric Blake <eblake@redhat= .com> wrote:
In today's Austin Group call, we discussed the fact that printf(1) = has
mandated behavior for %b (escape sequence processing similar to XSI
echo) that will eventually conflict with C2x's desire to introduce %b to printf(3) (to produce 0b000... binary literals).

For POSIX Issue 8, we plan to mark the current semantics of %b in
printf(1) as obsolescent (it would continue to work, because Issue 8
targets C17 where there is no conflict with C2x), but with a Future
Directions note that for Issue 9, we could remove %b entirely, or
(more likely) make %b output binary literals just like C.=C2=A0 But that raises the question of whether the escape-sequence processing
semantics of %b should still remain available under the standard,
under some other spelling, since relying on XSI echo is still not
portable.

One of the observations made in the meeting was that currently, both
the POSIX spec for printf(1) as seen at [1], and the POSIX and C
standard (including the upcoming C2x standard) for printf(3) as seen
at [3] state that both the ' and # flag modifiers are currently
undefined when applied to %s.

[1] https://pubs.op= engroup.org/onlinepubs/9699919799/utilities/printf.html
"The format operand shall be used as the format string described in XBD File Format Notation[2] with the following exceptions:..."

[2] https:= //pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05
"The flag characters and their meanings are: ...
# The value shall be converted to an alternative form. For c, d, i, u,
=C2=A0 and s conversion specifiers, the behavior is undefined.
[and no mention of ']"

[3] https://pubs.op= engroup.org/onlinepubs/9699919799/functions/printf.html
"The flag characters and their meanings are:
' [CX] [Option Start] (The <apostrophe>.) The integer portion of = the
=C2=A0 result of a decimal conversion ( %i, %d, %u, %f, %F, %g, or %G )
=C2=A0 shall be formatted with thousands' grouping characters. For othe= r
=C2=A0 conversions the behavior is undefined. The non-monetary grouping
=C2=A0 character is used. [Option End]
...
# Specifies that the value is to be converted to an alternative
=C2=A0 form. For o conversion, it shall increase the precision, if and only=
=C2=A0 if necessary, to force the first digit of the result to be a zero =C2=A0 (if the value and precision are both 0, a single 0 is printed). For<= br> =C2=A0 x or X conversion specifiers, a non-zero result shall have 0x (or =C2=A0 0X) prefixed to it. For a, A, e, E, f, F, g, and G conversion
=C2=A0 specifiers, the result shall always contain a radix character, even<= br> =C2=A0 if no digits follow the radix character. Without this flag, a radix<= br> =C2=A0 character appears in the result of these conversions only if a digit=
=C2=A0 follows it. For g and G conversion specifiers, trailing zeros shall<= br> =C2=A0 not be removed from the result as they normally are. For other
=C2=A0 conversion specifiers, the behavior is undefined."

Thus, it appears that both %#s and %'s are available for use for
future standardization.=C2=A0 Typing-wise, %#s as a synonym for %b is
probably going to be easier (less shell escaping needed).=C2=A0 Is there any interest in a patch to coreutils or bash that would add such a
synonym, to make it easier to leave that functionality in place for
POSIX Issue 9 even when %b is repurposed to align with C2x?

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:=C2=A0 qemu.org | libguestfs.org


--00000000000063120706044dd280-- From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 01 Sep 2023 18:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Phi Debian , 65659@debbugs.gnu.org, bug-bash@gnu.org, austin-group-l@opengroup.org, chet.ramey@case.edu Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.16935918447496 (code B ref 65659); Fri, 01 Sep 2023 18:11:01 +0000 Received: (at 65659) by debbugs.gnu.org; 1 Sep 2023 18:10:44 +0000 Received: from localhost ([127.0.0.1]:33841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc8bU-0001wp-2B for submit@debbugs.gnu.org; Fri, 01 Sep 2023 14:10:44 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:46233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc8bS-0001wb-9A for 65659@debbugs.gnu.org; Fri, 01 Sep 2023 14:10:42 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 739321C0002; Fri, 1 Sep 2023 18:10:25 +0000 (UTC) Date: Fri, 1 Sep 2023 19:10:24 +0100 From: Stephane Chazelas Message-ID: <20230901181024.pwx4plwclz7ijv5a@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GND-Sasl: stephane@chazelas.org X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: [...] > > Well in all case %b can not change semantic in the bash script, since it is > > there for so long, even if it depart from python, perl, libc, it is > > unfortunate but that's the way it is, nobody want a semantic change, and on > > next routers update, see the all internet falling appart :-) > > How many scripts in the wild actually use %b, though? And if there > are such scripts, anything we can do to make it easy to do a drop-in > replacement that still preserves the old behavior (such as changing %b > to %#s) is going to be easier to audit than the only other > currently-portable alternative of actually analyzing the string to see > if it uses any octal or \c escapes that have to be re-written to > portably function as a printf format argument. [...] FWIW, a "printf %b" github shell code search returns ~ 29k entries (https://github.com/search?q=printf+%25b+language%3AShell&type=code&l=Shell) That likely returns only a small subset of the code that uses printf with %b inside the format and probably a few false positives, but that gives many examples of how printf %b is used in practice. printf %b is also what all serious literature about shell scripting has been recommending to use in place of the unportable echo -e (or XSI echo, or print without -r). That includes the POSIX standard which has been recommending using printf instead of the non-portable echo for 30 years. So that change will also invalidate all those. It will take a while before %#s is supported widely enough that %b can be safely replaced with %#s -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Steffen Nurpmeso Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 02 Sep 2023 08:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: "Stephane Chazelas via austin-group-l at The Open Group" Cc: chet.ramey@case.edu, Phi Debian , bug-bash@gnu.org, 65659@debbugs.gnu.org, Eric Blake , Steffen Nurpmeso Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169364305719537 (code B ref 65659); Sat, 02 Sep 2023 08:25:03 +0000 Received: (at 65659) by debbugs.gnu.org; 2 Sep 2023 08:24:17 +0000 Received: from localhost ([127.0.0.1]:35093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcLvT-00054w-Vi for submit@debbugs.gnu.org; Sat, 02 Sep 2023 04:24:16 -0400 Received: from sdaoden.eu ([217.144.132.164]:38674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcBhO-0003Nq-Mt for 65659@debbugs.gnu.org; Fri, 01 Sep 2023 17:29:03 -0400 Date: Fri, 01 Sep 2023 23:28:50 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso Message-ID: <20230901212850.lwwbq%steffen@sdaoden.eu> In-Reply-To: <20230901181024.pwx4plwclz7ijv5a@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <20230901181024.pwx4plwclz7ijv5a@chazelas.org> Mail-Followup-To: "Stephane Chazelas via austin-group-l at The Open Group" , Eric Blake , Phi Debian , chet.ramey@case.edu, 65659@debbugs.gnu.org, bug-bash@gnu.org, Steffen Nurpmeso User-Agent: s-nail v14.9.24-507-g0e7e3e8c46 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spam-Score: -0.0 (/) X-Mailman-Approved-At: Sat, 02 Sep 2023 04:24:13 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stephane Chazelas via austin-group-l at The Open Group wrote in <20230901181024.pwx4plwclz7ijv5a@chazelas.org>: |2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: ... |> How many scripts in the wild actually use %b, though? And if there |> are such scripts, anything we can do to make it easy to do a drop-in |> replacement that still preserves the old behavior (such as changing %b |> to %#s) is going to be easier to audit than the only other |> currently-portable alternative of actually analyzing the string to see |> if it uses any octal or \c escapes that have to be re-written to |> portably function as a printf format argument. |[...] | |FWIW, a "printf %b" github shell code search returns ~ 29k |entries |(https://github.com/search?q=printf+%25b+language%3AShell&type=code&l=Sh\ |ell) | |That likely returns only a small subset of the code that uses |printf with %b inside the format and probably a few false |positives, but that gives many examples of how printf %b is used |in practice. Actually this returns a huge amount of false positives where printf(1) and %b are not on the same line, let alone the same command, if you just scroll down a bit it starts like neovim match pr_title="${pr_title// /,}" # Replace spaces with commas. pr_title="$(printf 'vim-patch:%s' "${pr_title#,}")" (bash only btw). Furthermore it shows a huge amount of false use cases like printf >&2 "%b\n" "The following warnings and non-fatal errors were encountered during the installation process:" This is only the first result page. It seems people think you need this to get colours mostly, which then, it has to be said, is also practically mislead. (To the best of *my* knowledge that is.) Ah it is a copy&paste world, and for one Stephane at stackoverflow there are 99 that fool and mislead you, or do not know for sure themselves, but also copy and paste! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Phi Debian Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 02 Sep 2023 08:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Stephane Chazelas Cc: 65659@debbugs.gnu.org, Eric Blake , bug-bash@gnu.org, austin-group-l@opengroup.org, chet.ramey@case.edu Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169364305819559 (code B ref 65659); Sat, 02 Sep 2023 08:25:03 +0000 Received: (at 65659) by debbugs.gnu.org; 2 Sep 2023 08:24:18 +0000 Received: from localhost ([127.0.0.1]:35099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcLvV-00055K-Sw for submit@debbugs.gnu.org; Sat, 02 Sep 2023 04:24:18 -0400 Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]:52704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcJTA-0006kH-I8 for 65659@debbugs.gnu.org; Sat, 02 Sep 2023 01:46:53 -0400 Received: by mail-vs1-xe30.google.com with SMTP id ada2fe7eead31-44e84fbaab9so1172312137.1 for <65659@debbugs.gnu.org>; Fri, 01 Sep 2023 22:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693633596; x=1694238396; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4VCZ1ZNvWzNPDfUvT8UJcOdjWfbFgqZmTtiSfSiWsHM=; b=MWPw63o6uDTvV9SoarWLh1IYWiXAa4FeRO0cjtNKSs6Hv1W5tPkTpviUpuTdUbEr5g pGdlRZ2pN6R+U2cLNvHaNdKgT4Nei3n3kt5fSdmtBwW8Y4FL5IbQpllsm8B/9JoqmDGa rswKudbOPGIecLftAQTUJZB/GXRsDhkITPg5WoExyjNURZKehFdxTvh/JK/INqSONuES du+/VRGkxCVFN5ukVbBTSejvjHIaZIpuXtHavtT13jB+eS6aEBWpolAt0ia/fGBMXaZW 4d+NAkeSZQ8EC+PDuKTaHuL1aGXc8smt6bOr6iOJsbuBC5vvvXZAviIO39xGtEL25nYd Wqhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693633596; x=1694238396; h=cc: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=4VCZ1ZNvWzNPDfUvT8UJcOdjWfbFgqZmTtiSfSiWsHM=; b=bwnFHqLViOaC/pr8LqE4HyVLjNzQB18ya4Bwt/wjoesXcQuio8NQQC69xWV1CP0rAQ MO9u7Pb319+Gwq7agbmoz7A4in/s+dOAOxPFB7THUDiWirHNA/d8IJYqqZonH+Ug98s6 Yh97NQpE/bUvR5FAStJq9K28Zk5kMKX0fJlOtegjikP2PMf/EEoKFjuFQeUlP2fEi54X m/AITNZ8P70o7kzcaJZVFi2vlf+yWK4U/AadtfVRRcdRUsVpaiWTBhjve1PpEKcnopG/ y1oHprV/5Cf6GMxV64gZIGWJfmYRyftN18HcdrUsbOeT0w/K6lLWdvdkOzrkIDnYzXFr OdMA== X-Gm-Message-State: AOJu0YzsakgTOWSdLqgmceR45WZCMSoU8BlYV1ziMajpDWZCrxHg30gl bZFzUfURD5KYb4//gsgDjhY0+++0xAm4KvPgtAM= X-Google-Smtp-Source: AGHT+IEx1Jem2lnY9DfDP8WybkXAXD+DJkHozIpci/12s7lzT0isiU18sD1zUOzIpWDkVTwi856X/nXU5FhqJaEbYSg= X-Received: by 2002:a67:ff8b:0:b0:44d:4dd6:7964 with SMTP id v11-20020a67ff8b000000b0044d4dd67964mr4691511vsq.6.1693633596678; Fri, 01 Sep 2023 22:46:36 -0700 (PDT) MIME-Version: 1.0 References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <20230901181024.pwx4plwclz7ijv5a@chazelas.org> In-Reply-To: <20230901181024.pwx4plwclz7ijv5a@chazelas.org> From: Phi Debian Date: Sat, 2 Sep 2023 07:46:25 +0200 Message-ID: Content-Type: multipart/alternative; boundary="000000000000e8e5c6060459cc70" X-Spam-Score: 0.0 (/) X-Mailman-Approved-At: Sat, 02 Sep 2023 04:24:13 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000e8e5c6060459cc70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 1, 2023 at 8:10=E2=80=AFPM Stephane Chazelas wrote: > 2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Grou= p: > > > FWIW, a "printf %b" github shell code search returns ~ 29k > entries > ( > https://github.com/search?q=3Dprintf+%25b+language%3AShell&type=3Dcode&l= =3DShell > ) > > Ha super, at least some numbers :-), I didn't knew we could make this kind of request... thanx for that. --000000000000e8e5c6060459cc70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 1, 2023 at 8:10=E2=80=AFP= M Stephane Chazelas <stephane@c= hazelas.org> wrote:
2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at= The Open Group:


FWIW, a "printf %b" github shell code search returns ~ 29k
entries
(https://git= hub.com/search?q=3Dprintf+%25b+language%3AShell&type=3Dcode&l=3DShe= ll)


Ha super, at least some numbers = :-), I didn't knew we could make this kind of request... thanx for that= .

=C2= =A0
--000000000000e8e5c6060459cc70-- From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Stephane Chazelas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 02 Sep 2023 08:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Stephane Chazelas via austin-group-l at The Open Group , Eric Blake , Phi Debian , chet.ramey@case.edu, 65659@debbugs.gnu.org, bug-bash@gnu.org, Steffen Nurpmeso Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.169364457122388 (code B ref 65659); Sat, 02 Sep 2023 08:50:02 +0000 Received: (at 65659) by debbugs.gnu.org; 2 Sep 2023 08:49:31 +0000 Received: from localhost ([127.0.0.1]:35137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcMJv-0005p2-Fs for submit@debbugs.gnu.org; Sat, 02 Sep 2023 04:49:31 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:48881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcMJu-0005op-CI for 65659@debbugs.gnu.org; Sat, 02 Sep 2023 04:49:30 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id E541EC0003; Sat, 2 Sep 2023 08:49:12 +0000 (UTC) Date: Sat, 2 Sep 2023 09:49:12 +0100 From: Stephane Chazelas Message-ID: <20230902084912.vdfedsgbnat2w25n@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <20230901181024.pwx4plwclz7ijv5a@chazelas.org> <20230901212850.lwwbq%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230901212850.lwwbq%steffen@sdaoden.eu> X-GND-Sasl: stephane@chazelas.org X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The Open Group: [...] > |FWIW, a "printf %b" github shell code search returns ~ 29k > |entries > |(https://github.com/search?q=printf+%25b+language%3AShell&type=code&l=Sh\ > |ell) > | > |That likely returns only a small subset of the code that uses > |printf with %b inside the format and probably a few false > |positives, but that gives many examples of how printf %b is used > |in practice. > > Actually this returns a huge amount of false positives where > printf(1) and %b are not on the same line, let alone the same > command, if you just scroll down a bit it starts like neovim match [...] You're right, I only looked at the first few results and saw that already gave interesting ones. Apparently, we can also search with regexps and searching for printf.*%b (https://github.com/search?q=%2Fprintf.*%25b%2F+language%3AShell&type=code) It's probably a lot more accurate. It returns ~ 19k. (still FWIW, that's still just a sample of random code on the internet) [...] > Furthermore it shows a huge amount of false use cases like > > printf >&2 "%b\n" "The following warnings and non-fatal errors were encountered during the installation process:" [...] Yes, I also see a lot of echo -e stuff that should have been echo -E stuff (or echo alone in those (many) implementations that don't expand by default or use the more reliable printf with %s (not %b)). > It seems people think you need this to get colours mostly, which > then, it has to be said, is also practically mislead. (To the > best of *my* knowledge that is.) [...] Incidentally, ANSI terminal colour escape sequences are somewhat connecting those two %b's as they are RGB (well BGR) in binary (white is 7 = 0b111, red 0b001, green 0b010, blue 0b100), with: R=0 G=1 B=1 printf '%bcyan%b\n' "\033[3$(( 2#$B$G$R ))m" '\033[m' (with Korn-like shells, also $(( 0b$B$G$R )) in zsh though zsh has builtin colour output support including RGB-based). Speaking of stackexchange, on the June data dump of unix.stackexchange.com: stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf.*%b' 494 (FWIW) Compared with %d (though that will have entries for printf(3) as well): stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf.*%d' 3444 -- Stephane From unknown Sat Aug 09 01:33:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65659: RFC: changing printf(1) behavior on %b Resent-From: Steffen Nurpmeso Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 02 Sep 2023 18:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65659 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Stephane Chazelas Cc: chet.ramey@case.edu, Stephane Chazelas via austin-group-l at The Open Group , Phi Debian , bug-bash@gnu.org, 65659@debbugs.gnu.org, Eric Blake , Steffen Nurpmeso Received: via spool by 65659-submit@debbugs.gnu.org id=B65659.16936784764014 (code B ref 65659); Sat, 02 Sep 2023 18:15:01 +0000 Received: (at 65659) by debbugs.gnu.org; 2 Sep 2023 18:14:36 +0000 Received: from localhost ([127.0.0.1]:38608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcV8m-00012f-63 for submit@debbugs.gnu.org; Sat, 02 Sep 2023 14:14:36 -0400 Received: from sdaoden.eu ([217.144.132.164]:50982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcV8h-00012U-3x for 65659@debbugs.gnu.org; Sat, 02 Sep 2023 14:14:34 -0400 Date: Sat, 02 Sep 2023 19:57:11 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso Message-ID: <20230902175711.y4xm9%steffen@sdaoden.eu> In-Reply-To: <20230902084912.vdfedsgbnat2w25n@chazelas.org> References: <37178eea-eb8f-37f1-df1a-6aa94f51c6c1@case.edu> <20230901181024.pwx4plwclz7ijv5a@chazelas.org> <20230901212850.lwwbq%steffen@sdaoden.eu> <20230902084912.vdfedsgbnat2w25n@chazelas.org> Mail-Followup-To: Stephane Chazelas , Stephane Chazelas via austin-group-l at The Open Group , Eric Blake , Phi Debian , chet.ramey@case.edu, 65659@debbugs.gnu.org, bug-bash@gnu.org, Steffen Nurpmeso User-Agent: s-nail v14.9.24-507-g0e7e3e8c46 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stephane Chazelas wrote in <20230902084912.vdfedsgbnat2w25n@chazelas.org>: |2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \ |Open Group: ... |>|FWIW, a "printf %b" github shell code search returns ~ 29k |>|entries |>|(https://github.com/search?q=printf+%25b+language%3AShell&type=code&l=Sh\ |>|ell) ... |> Actually this returns a huge amount of false positives where |> printf(1) and %b are not on the same line, let alone the same ... |Apparently, we can also search with regexps and searching for |printf.*%b |(https://github.com/search?q=%2Fprintf.*%25b%2F+language%3AShell&type=code) |It's probably a lot more accurate. It returns ~ 19k. ... |> Furthermore it shows a huge amount of false use cases like ... |Yes, I also see a lot of echo -e stuff that should have been |echo -E stuff (or echo alone in those (many) implementations |that don't expand by default or use the more reliable printf |with %s (not %b)). | |> It seems people think you need this to get colours mostly, which ... |Incidentally, ANSI terminal colour escape sequences are somewhat |connecting those two %b's as they are RGB (well BGR) in binary |(white is 7 = 0b111, red 0b001, green 0b010, blue 0b100), with: | |R=0 G=1 B=1 |printf '%bcyan%b\n' "\033[3$(( 2#$B$G$R ))m" '\033[m' | |(with Korn-like shells, also $(( 0b$B$G$R )) in zsh though zsh |has builtin colour output support including RGB-based). ..and, off-topic, but in my opinion that is also false usage, one should use tput(1) instead, and then simply printf(1) (or echo(1) (or cat(1))) the output, something like, fwiw :), color_init() { [ -n "${NO_COLOUR}" ] && return # We do not want color for "make test > .LOG"! if [ -t 1 ] && command -v tput >/dev/null 2>&1; then { sgr0=$(tput sgr0); } 2>/dev/null [ $? -eq 0 ] || return { saf1=$(tput setaf 1); } 2>/dev/null [ $? -eq 0 ] || return { saf2=$(tput setaf 2); } 2>/dev/null [ $? -eq 0 ] || return { saf3=$(tput setaf 3); } 2>/dev/null [ $? -eq 0 ] || return { saf5=$(tput setaf 5); } 2>/dev/null [ $? -eq 0 ] || return { b=$(tput bold); } 2>/dev/null [ $? -eq 0 ] || return COLOR_ERR_ON=${saf1}${b} COLOR_ERR_OFF=${sgr0} COLOR_DBGERR_ON=${saf5} COLOR_DBGERR_OFF=${sgr0} COLOR_WARN_ON=${saf3}${b} COLOR_WARN_OFF=${sgr0} COLOR_OK_ON=${saf2} COLOR_OK_OFF=${sgr0} unset saf1 saf2 saf3 b fi } ... printf '%s%s%s' "${COLOR_WARN_ON}" "$SOME_MSG" "${COLOR_WARN_OFF}" Of course this is also only ANSI via sgr0 (:-| |Speaking of stackexchange, on the June data dump of |unix.stackexchange.com: | |stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf\ |.*%b' |494 | |(FWIW) | |Compared with %d (though that will have entries for printf(3) as well): | |stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf\ |.*%d' |3444 I am totally stunned by the ratio. I myself have never used %b (like this, aka for printf). --End of <20230902084912.vdfedsgbnat2w25n@chazelas.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)