Re: [PATCH] printf: add %#s alias to %b

[Oğuz]

On Wed, Sep 6, 2023 at 9:38 AM Robert Elz  wrote:
> Adding a different %b to printf(1) wasn't currently even proposed, just
> deprecating the current one so it wouldn't conflict with the usage of
> %b in printf(3) (which is being defined in C23, and is apparently already
> firmly entrenched, even though C23 is not yet (quite) formally released).
>
> There was no proposal (yet) to provide a replacement for %b (which would
> not actually be deprecated, if it were to be, for ages yet) - though the
> %#s idea was proposed, and implemented in a couple of places (incl bash
> I believe) - technically according to the rules, it would be too late now
> to even mention that in the upcoming POSIX version, though there was some
> talk of bending that rule, so a hint could be provided to applications as
> to how they might move away from %b (the existing proposal is nonsense).
>
> My guess is that none of this will happen now, and %b, or possible alternates,
> won't get any special mention in the forthcoming POSIX standard - so %b
> in printf(1) would remain just like it is now for several decades at least.
> (%b will appear in POSIX printf(3) in the next version after this one,
> when POSIX aligns itself with C23 (or later) which contains that - C23 is
> too late to be considered for the forthcoming POSIX version, and C17 does not
> contain %b in its printf function).

Thanks. This entire discussion is nonsense; a proposal to deprecate a
useful feature appears out of the blue, patches are sent, alternatives
are listed, a whole fuss is made. Yet the only argument supporting
said deprecation is maintaining consistency with C23. Why is it
important to do that? No answer. It's nonsense.

I don't think bash should deprecate %b. If a built-in way to convert
to/from bases other than 8 and 16 is desired, bash can do it like ksh
does or invent a new way. But breaking backwards compatibility so that
you can say "well, at least my shell is consistent with C23" would be
plain idiocy.

>
> kre
>
>

Re: [PATCH] printf: add %#s alias to %b

[Dragan Simic]

On 2023-09-06 05:45, Robert Elz wrote:

Date:Tue, 05 Sep 2023 22:32:39 +0200
From:Dragan Simic 
Message-ID:  <7cfed11b50d35cbfaaa647c1fcd39...@manjaro.org>

  | Are there any official explanations why is the invalidation 
actually

  | happening now?

It was proposed because of a desire to keep the formats for printf(1)
and printf(3) the same (they're not really anyway, but they generally
don't actually conflict currently).

No invalidation would be happening now, merely a note in the coming 
standard

that the %b in printf(1) would (might) be removed in a later version of
the standard - so implementations have time to implement something to
replace it, and applications to stop using %b in printf(1).   The next
version of the standard isn't likely for at least another decade (the
coming one isn't finished yet, and that's not the next that counts 
here,

and later issues that are merely corrections (TCs) don't count either).
[As a reference for timelines, the current POSIX standard is from 2008,
though a couple of TCs have followed it - that's 15 years already
between versions.]


Thank you for this detailed clarification.  It's good to know that the 
2013, 2016 and 2018 versions/revisions of POSIX actually don't count.



However, my "read of the room" at the minute is that this simply won't
happen, and printf(1) %b will remain as it is, and not be removed any
time soon (or probably, ever).   If printf(1) ever really needs a 
method

to output in binary, some other mechanism is likely to be found - most
likely one which gives a choice of output bases, not just base 2.

There's no current harm implementing %#s as an alias for %b - but I see
no point in anyone using it, it will certainly be far less portable 
than
%b for a LONG time.   There's also no guarantee that the C people might 
not
find a use in printf(3) for %#s (currently the # there has no meaning) 
and
entirely possible that whatever that use is, if it happens, might be 
more

useful for printf(1) to follow, than having it mean what %b currently
means - so going that route really is not a safe long term choice (it
would be a gamble).

kre

Re: [PATCH] printf: add %#s alias to %b

[Chet Ramey]

On 9/5/23 7:34 PM, Rob Landley wrote:


C23 is going to use %b to print binary literals.


Upper case %B was taken?


I asked the same question. The short answer is that no one trusts the C
committee.

https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00121.html


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH] printf: add %#s alias to %b

[Chet Ramey]

On 9/5/23 10:13 PM, William Bader wrote:

Has bash ever had a change before that would break valid scripts?


Yes, but I try to keep those to a minimum.

Could the printf format change be settable by a variable or by an option 
like the -e/-E in echo?


It could, sure. Anything is possible.


Is it necessary for bash printf to match C printf?


No. That's the heart of it.


I suppose that it is already decided.


The austin group has decided what they'd like to do, and what they'd like
implementors to do. The question is whether or not people go along with it.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH] printf: add %#s alias to %b

[Chet Ramey]

On 9/6/23 6:28 AM, Dragan Simic wrote:


No invalidation would be happening now, merely a note in the coming standard
that the %b in printf(1) would (might) be removed in a later version of
the standard - so implementations have time to implement something to
replace it, and applications to stop using %b in printf(1).   The next
version of the standard isn't likely for at least another decade (the
coming one isn't finished yet, and that's not the next that counts here,
and later issues that are merely corrections (TCs) don't count either).
[As a reference for timelines, the current POSIX standard is from 2008,
though a couple of TCs have followed it - that's 15 years already
between versions.]


Thank you for this detailed clarification.  It's good to know that the 
2013, 2016 and 2018 versions/revisions of POSIX actually don't count.


That's not what he said.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH] printf: add %#s alias to %b

[Chet Ramey]

On 9/6/23 4:02 AM, Oğuz wrote:

I don't think bash should deprecate %b. 


I don't have any plans to change %b.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Bash runs into segmentation fault (malloc: block on free list clobbered)

[Dang Tan Hoa]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib
 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall
uname output: Linux mcgrath 3.13.0-117-generic #164~precise1-Ubuntu SMP Mon
Apr 10 16:16:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.1.16
Patch Level: 16
Release Status: release

Description:
Sometimes, Bash runs into segmentation-fault due to memory
management (malloc: block on free list clobbered).

<>
GNU gdb (GDB) 7.6.1

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "arm-unknown-linux-gnueabi".

For bug reporting instructions, please see:

...

Reading symbols from /bin/bash...done.

[New LWP 5525]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/libthread_db.so.1".

Core was generated by `/bin/bash -l -'.

Program terminated with signal 6, Aborted.

#0 0xb6d62c84 in raise () from /lib/libc.so.6

Thread 1 (Thread 0xb6f23000 (LWP 5525)):

#0 0xb6d62c84 in raise () from /lib/libc.so.6

No symbol table info available.

#1 0xb6d63fcc in abort () from /lib/libc.so.6

No symbol table info available.

#2 0x00050e78 in programming_error (

format=0x10af48 "malloc: block on free list clobbered")

at /home/sw/tps/bash/error.c:175

args = {__ap = 0xbe9c9194}

h = 

#3 0x000efd1c in xbotch (mem=mem@entry=0x2030c38, e=e@entry=0,

s=0x10af48 "malloc: block on free list clobbered",

file=file@entry=0xf447c "/home/sw/tps/bash/make_cmd.c", line=line@entry
=91)

at /home/sw/tps/bash/lib/malloc/malloc.c:376

No locals.

#4 0x000f0994 in internal_malloc (n=n@entry=3,

file=file@entry=0xf447c "/home/sw/tps/bash/make_cmd.c", line=line@entry=91,
flags=flags@entry=1)

at /home/sw/tps/bash/lib/malloc/malloc.c:882

p = 0x2030c30

nunits = 1

m = 

z = 

nbytes = 16

#5 0x000f0fe4 in sh_malloc (bytes=bytes@entry=3,

file=file@entry=0xf447c "/home/sw/tps/bash/make_cmd.c", line=line@entry
=91)

at /home/sw/tps/bash/lib/malloc/malloc.c:1360

No locals.

#6 0x00092314 in sh_xmalloc (bytes=3,

file=0xf447c "/home/sw/tps/bash/make_cmd.c", line=line@entry=91)

at /home/sw/tps/bash/xmalloc.c:223

temp = 

#7 0x000378e0 in make_bare_word (string=0x1ff9418 "-e")

at /home/sw/tps/bash/make_cmd.c:91

temp = 0x2056728

#8 0x00050304 in copy_word (w=0x1ffac48)

at /home/sw/tps/bash/copy_cmd.c:61

new_word = 0x10af48

#9 0x000503f4 in copy_word_list (list=0x1ffac68)

at /home/sw/tps/bash/copy_cmd.c:80

new_list = 0x230c9e8

tl = 

#10 0x000509d0 in copy_simple_command (com=0x1ffabe8)

at /home/sw/tps/bash/copy_cmd.c:333

new_simple = 0x2310e68

#11 copy_command (command=)

at /home/sw/tps/bash/copy_cmd.c:439

new_command = 0x2307528

#12 0x0005091c in copy_if_command (com=0x1ffaba8)

at /home/sw/tps/bash/copy_cmd.c:284

new_if = 0x2311a68

#13 copy_command (command=)

at /home/sw/tps/bash/copy_cmd.c:423

new_command = 0x23108e8

#14 0x00050a44 in copy_command (command=0x1fdce68)

at /home/sw/tps/bash/copy_cmd.c:449

new_connection = 0x22ecf48

new_command = 0x2311768

#15 0x00050704 in copy_group_command (com=0x1fdce48)

at /home/sw/tps/bash/copy_cmd.c:219

new_group = 0x230bf48

#16 copy_command (command=)

at /home/sw/tps/bash/copy_cmd.c:402

new_command = 0x23100e8

#17 0x00044c14 in execute_function (var=var@entry=0x1fdce08,

words=words@entry=0x2310ec8, flags=flags@entry=32768,

fds_to_close=fds_to_close@entry=0x230bee8, async=async@entry=0,

subshell=subshell@entry=0)

at /home/sw/tps/bash/execute_cmd.c:5043

return_val = 

result = 

tc = 

fc = 

save_current = 

debug_trap = 

error_trap = 

return_trap = 

funcname_v = 0x1fd3348

bash_source_v = 0x1fd2f88

bash_lineno_v = 0x1fd3088

funcname_a = 0x1fd33c8

bash_source_a = 0x1fd3008

bash_lineno_a = 0x1fd3148

fa = 

shell_fn = 

sfile = 

t = 

gs = 

gv = 

#18 0x00040820 in execute_builtin_or_function (flags=32768,

fds_to_close=0x230bee8, redirect

Re: [PATCH] printf: add %#s alias to %b

[William Bader]

Has bash ever had a change before that would break valid scripts?

Could the printf format change be settable by a variable or by an option like 
the -e/-E in echo?

Is it necessary for bash printf to match C printf?

I suppose that it is already decided.

Could the bash printf implementation warn if the new %b is passed something 
that doesn't look like a numeric string?

Does shellcheck track variables well enough to warn if the new %b is passed 
something that doesn't look like a numeric string?

Regards, William


From: coreutils-bounces+williambader=hotmail@gnu.org 
 on behalf of Chet Ramey 

Sent: Tuesday, September 5, 2023 4:44 PM
To: Dragan Simic 
Cc: chet.ra...@case.edu ; enh ; Eric 
Blake ; Rob Landley ; coreut...@gnu.org 
; bug-bash@gnu.org 
Subject: Re: [PATCH] printf: add %#s alias to %b

On 9/5/23 4:32 PM, Dragan Simic wrote:
> On 2023-09-05 22:25, Chet Ramey wrote:
>> On 9/5/23 3:58 PM, enh wrote:
>>> On Fri, Sep 1, 2023 at 6:59 AM Chet Ramey  wrote:
>>
 I think you'll find that, regardless of its origins, there are more
 scripts
 using the %b specifier than you think.
>>>
>>> i'd personally never heard of printf(1) %b before this thread, but
>>> debian code search agrees with you:
>>
>> It's a POSIX invention dating from at least 1991 (P1003.2-D11).
>>
>> The POSIX guidance to use it as a portable way to replace SysV echo has
>> dated from the same time. It's a pretty big lift to suddenly invalidate
>> all that prior art. ("POSIX giveth, and POSIX taketh away.").
>
> Are there any official explanations why is the invalidation actually
> happening now?

https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00112.html

C23 is going to use %b to print binary literals.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH] printf: add %#s alias to %b

[Greg Wooledge]

On Wed, Sep 06, 2023 at 02:13:44AM +, William Bader wrote:
> Has bash ever had a change before that would break valid scripts?

Yes.  Many times, sadly.  Most recently, bash 5.2 introduced some changes
to how associative array indexes are handled, which will break
backward compatibility in several ways.

The changing of how "set -e" is handled (several times, mostly driven
by POSIX) has also caused scripts to work differently.

There are lots more examples, but those are the ones I think of first.

> Could the printf format change be settable by a variable or by an option like 
> the -e/-E in echo?
> 
> Is it necessary for bash printf to match C printf?
> 
> I suppose that it is already decided.

Chet has answered these.

> Does shellcheck track variables well enough to warn if the new %b is passed 
> something that doesn't look like a numeric string?

There isn't a "new %b", so this question is theoretical.  Shellcheck is
an independent project, and if a new printf format were to be introduced,
you could talk to its developer about getting the relevant changes into
shellcheck in a timely fashion -- again, theoretically.

hash -d 0/1 and other hash stuff

[Mike Jonkmans]

The following 'hash -d' statements have different exit statuses.

bash --noprofile --norc -c \
'hash -d ls; echo $?' ## 0
bash --noprofile --norc -c \
'cat /dev/null; echo $?' ## 1

This depends on a hashable command being given (e.g. cat https://pubs.opengroup.org/onlinepubs/9699919799/utilities/hash.html)
only has -r as option.

FWIW: 
https://github.com/search?q=language%3AShell+content%3A%2F%28%5E%7C%5B%5B%3Ablank%3A%5D%5D%29hash%5B%5B%3Ablank%3A%5D%5D-d%2F+NOT+zsh&type=code

Simple patch attached, making 'hash -d ls' exit with 1 in the first case also.
But ...


Questions

1) Why is 'hash -d x' exiting with 1 at all? If the goal is to `unhash x',
'hash -d x' will do the job. Even if x was not hashed at all.
But I am not sure that such a change is feasible (backwards compatible).


2) 'hash x' and 'hash -l x' seem to do the same
(i.c. path search and add to hash if found).
It would be more useful to let 'hash -l x' give the 'hash -l' output for x.
Moreover, I find it unexpected that 'hash -l x' adds x to the hash.
A quick look on github, shows no use of 'hash -l x',
so changes might be ok.

'hash -lt x' outputs what I would have expected 'hash -l x' to do.
Note that 'hash -lt x' doesn't add x to the hash (unexpected).


3) These option combinations should error/exit 1:
Ignoring the '-p path' part:
hash -p path
hash -p path -t name
hash -p path -l
hash -p path -r

This adds name, using path, but ignores the other option:
hash -p path -l name
hash -p path -d name

Using -t ignores -d:
hash ls; hash -td ls

And -d ignores -l:
hash ls; hash -ld ls


Conclusion
I would say that:
- Combining options should error;
- Except for an added -r, which first clears;
- 'hash -l x' shouldn't add, but print what 'hash -lt x' currently prints;
- 'hash -d x' always exits 0, quietly.

Let me know if any of this stuff is wanted, I think I can implement this.

-- 
Regards, Mike Jonkmans
 hashcmd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git i/hashcmd.c w/hashcmd.c
index ebb92346..62e080be 100644
--- i/hashcmd.c
+++ w/hashcmd.c
@@ -66,9 +66,12 @@ phash_remove (const char *filename)
 {
   register BUCKET_CONTENTS *item;
 
-  if (hashing_enabled == 0 || hashed_filenames == 0)
+  if (hashing_enabled == 0)
 return 0;
 
+  if (hashed_filenames == 0)
+return 1;
+
   item = hash_remove (filename, hashed_filenames, 0);
   if (item)
 {

Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic 
Message-ID:  <03abecb9d905252bd63867d1c8b2a...@manjaro.org>

  | It's good to know that the 
  | 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.

As Chet said, that is not what I meant.   The "don't count" was in
relation to measuring the time between new versions, as TCs aren't
allowed to add or delete features (which actuslly removing %b from
printf(1) would be) only a whole new version can do that.

It is however possible that I misremembered the dates, and that it
was the 6th version which was 2008, with the 7th being 2013, or
something (the one currently nearing completion is #8).   Regardless,
it is clear that #9, which is the first possibility for removing
%b, assuming that #8 continues to say it might happen (which I
suspect it won't, but we'll see) is many years into the future yet.

kre

kre

Re: [PATCH] printf: add %#s alias to %b

[Dragan Simic]

On 2023-09-06 15:07, Chet Ramey wrote:

On 9/6/23 6:28 AM, Dragan Simic wrote:

No invalidation would be happening now, merely a note in the coming 
standard
that the %b in printf(1) would (might) be removed in a later version 
of

the standard - so implementations have time to implement something to
replace it, and applications to stop using %b in printf(1).   The 
next

version of the standard isn't likely for at least another decade (the
coming one isn't finished yet, and that's not the next that counts 
here,
and later issues that are merely corrections (TCs) don't count 
either).
[As a reference for timelines, the current POSIX standard is from 
2008,

though a couple of TCs have followed it - that's 15 years already
between versions.]


Thank you for this detailed clarification.  It's good to know that the 
2013,

2016 and 2018 versions/revisions of POSIX actually don't count.


That's not what he said.


Huh, quite frankly, this makes me confused a bit.  Now I'm wondering 
what actually are the 2013, 2016 and 2018 revisions of POSIX?  I'd 
really appreciate further clarification, but please keep in mind that 
I'm referring to the HTML stuff downloadable for free from The Open 
Group, such as the 2017/2018 revision linked below.


https://publications.opengroup.org/c181

Is the stated IEEE Std 1003.1 the right stuff at all?  The web page says 
that it also has a couple of TCs integrated, so I'd guess that it is the 
right stuff, which the link below also suggests by explaining IEEE Std 
1003.1 further.


https://standards.ieee.org/ieee/1003.1/7101/

Quite frankly, all this is confusing, and even more is confusing why 
such standards aren't available for free to anyone interested in that 
matter.  That's ridiculous, IMHO.

Re: [PATCH] printf: add %#s alias to %b

[Dragan Simic]

On 2023-09-06 17:10, Robert Elz wrote:

Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic 
Message-ID:  <03abecb9d905252bd63867d1c8b2a...@manjaro.org>

  | It's good to know that the
  | 2013, 2016 and 2018 versions/revisions of POSIX actually don't 
count.


As Chet said, that is not what I meant.   The "don't count" was in
relation to measuring the time between new versions, as TCs aren't
allowed to add or delete features (which actuslly removing %b from
printf(1) would be) only a whole new version can do that.

It is however possible that I misremembered the dates, and that it
was the 6th version which was 2008, with the 7th being 2013, or
something (the one currently nearing completion is #8).   Regardless,
it is clear that #9, which is the first possibility for removing
%b, assuming that #8 continues to say it might happen (which I
suspect it won't, but we'll see) is many years into the future yet.


Ah, I see, thank you for the clarification.  Your response arrived while 
I was writing my other message to the list, so I didn't see it before 
hitting the "send" button.

Re: Parse error in bash 5.2+ with CHLD trap and 2 or more $() in a command

[Chet Ramey]

On 9/5/23 7:00 PM, Emanuele Torre wrote:

If you have a CHLD trap set, and you run any command that has more than
one command substitution, or an array subscript with more than one
command substituion in an arithmetic context, or also in a prompt
string, you will get parse errors.


Thanks for the report.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH] printf: add %#s alias to %b

[Eric Blake]

On Wed, Sep 06, 2023 at 09:03:29AM -0400, Chet Ramey wrote:
> On 9/5/23 10:13 PM, William Bader wrote:
> > Has bash ever had a change before that would break valid scripts?
> 
> Yes, but I try to keep those to a minimum.
> 
> > Could the printf format change be settable by a variable or by an option
> > like the -e/-E in echo?
> 
> It could, sure. Anything is possible.
> 
> > Is it necessary for bash printf to match C printf?
> 
> No. That's the heart of it.
> 
> > I suppose that it is already decided.
> 
> The austin group has decided what they'd like to do, and what they'd like
> implementors to do. The question is whether or not people go along with it.

The Austin Group decided merely:

If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
between printf(1) and printf(3).  If we reach out to all developers
now, we can start the discussion, and then by the time Issue 9 comes
around (several years from now), we may have enough consensus to do
any number of things:

- Do nothing; printf(1) and printf(3) have incompatible %b
- Declare that %b has implementation-defined behavior (shell authors
  have the choice on whether %b has old or new behavior)
- Declare that %b is no longer standardized (but implementations can
  still provide it as an extension, using their choice of behavior)
- Standardize %#s to do the same thing as %b used to do
- Standardize 'printf -c %b 1' which parses its format string
  according to C23 rules (output "0b1"), while 'printf %b 1' remains
  the old way (output "1")
- Your suggestion here (if enough shell writers agree on what to do,
  then Issue 9 can do that)

But for that work, Issue 8 has to do something - it marks %b
obsolescent, merely so that we have the option (not the mandate) to
change its behavior in the future.  It may turn out that there is
enough resistance that the answer is no change to behavior, and we
could even remove the obsolescent tag in Issue 9 (that is, make it
formal that printf(1) and printf(3) intentionally diverge on %b).  But
marking something obsolescent in Issue 8 doesn't require any current
shell to change, while still encouraging the discussion in case they
do want to change.

Adding %#s as a synonym to %b seems easy enough to do, regardless of
what Issue 9 decides to do to %b, so the Austin Group mentioned that
as a non-normative idea in the wording for Issue 8.  But they are not
requiring shell authors to implement it (even though GNU Coreutils has
already expressed willingness to do it in /bin/printf).  Meanwhile,
implementing 'printf -c' to mean "interpret my format string according
to C23 semantics" is also a viable idea, but one not mentioned in the
current incantation of the Austin Group bug.  But that's why the bug
has a 30-day review period, to collect feedback comments on how it can
be better worded before Issue 8 is finalized.

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

Re: [PATCH] printf: add %#s alias to %b

[Eric Blake]

On Wed, Sep 06, 2023 at 10:45:09AM +0700, Robert Elz wrote:
> 
> However, my "read of the room" at the minute is that this simply won't
> happen, and printf(1) %b will remain as it is, and not be removed any
> time soon (or probably, ever).   If printf(1) ever really needs a method
> to output in binary, some other mechanism is likely to be found - most
> likely one which gives a choice of output bases, not just base 2.

You (anyone reading this, not just kre) are welcome to join tomorrow's
Austin Group meeting if you would like to add input on how to reword
the changes that will land in Issue 8 as a result of
https://austingroupbugs.net/view.php?id=1771; it is a Zoom call
(details at
https://www.mail-archive.com/austin-group-l@opengroup.org/msg11758.html).
Or you can add comments to the bug directly. I will be on the call,
and if nothing else, my role in the meeting tomorrow will include
summarizing some of the "read of the room" on the feedback received in
this thread (namely, enough shell authors are insistent that printf(1)
and printf(3) should diverge in %b behavior in Issue 9 that trying to
plan otherwise by marking it obsolescent in Issue 8 isn't going to
minimize any pain down the road)

> 
> There's no current harm implementing %#s as an alias for %b - but I see
> no point in anyone using it, it will certainly be far less portable than
> %b for a LONG time.   There's also no guarantee that the C people might not
> find a use in printf(3) for %#s (currently the # there has no meaning) and
> entirely possible that whatever that use is, if it happens, might be more
> useful for printf(1) to follow, than having it mean what %b currently
> means - so going that route really is not a safe long term choice (it
> would be a gamble).

Of course, the gamble is easier to win if we have multiple independent
implementations that have all coordinated to do it the same way, so we
can push back on WG14 to tell them they would be foolish to commandeer
%#s for anything other than what existing practice has.  Coreutils is
willing to do it, but I have not actually committed that patch yet,
waiting to see how this thread pans out.

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

Re: [PATCH] printf: add %#s alias to %b

[Chet Ramey]

On 9/6/23 12:03 PM, Eric Blake wrote:


The austin group has decided what they'd like to do, and what they'd like
implementors to do. The question is whether or not people go along with it.


The Austin Group decided merely:

If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
between printf(1) and printf(3).  If we reach out to all developers
now, we can start the discussion, and then by the time Issue 9 comes
around (several years from now), we may have enough consensus to do
any number of things:


They may have, but they kept it to themselves. According to Geoff Clare,
the group didn't go beyond various ways to deprecate %b:

"I think everyone in the teleconference just assumed that the inconsistency
is best avoided.  I don't recall living with it being discussed as an
option."

You introduced the topic as if deprecation/repurposing had already been
decided:

"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?"

So that group decided, at least initially, to deprecate %b immediately
and repurpose it in issue 9. They hoped that printf(1) implementors
would go along with it.

Now, maybe that group is reconsidering, since they are aware of other
points of view. There are indeed other options.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [PATCH] printf: add %#s alias to %b

[Rob Landley]

On 9/6/23 05:28, Dragan Simic wrote:
> Thank you for this detailed clarification.  It's good to know that the 
> 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.

You didn't change the URL. You didn't update the SUSvX number. It's still says
"issue 7" at the top. That's YOU telling US they don't count.

Rob

Re: [PATCH] printf: add %#s alias to %b

[Dragan Simic]

On 2023-09-07 03:03, Rob Landley wrote:

On 9/6/23 05:28, Dragan Simic wrote:

Thank you for this detailed clarification.  It's good to know that the
2013, 2016 and 2018 versions/revisions of POSIX actually don't count.


You didn't change the URL. You didn't update the SUSvX number. It's 
still says

"issue 7" at the top. That's YOU telling US they don't count.


Sorry, what do you mean?  I'm not saying or stating anything, I just 
asked for some additional clarification, so I can better understand the 
whole thing.  Robert Elz has already provided another detailed 
clarification in the mail linked below, which I really appreciate.


https://lists.gnu.org/archive/html/coreutils/2023-09/msg00018.html

Re: set -x vs. n=($@)

[Dan Jacobson]

OK. That's well and good. But my main problem now is that that fact is
not documented anywhere.

(Also here it is again, so as to remove any confusion about "compound
assignment" (some readers might think it meant two ='s on the same line.)

$ bash -c 'set a b c; set -x; m=$@; n=($@)'
+ m='a b c'
+ n=($@)

)
> "CR" == Chet Ramey  writes:
CR> On 9/3/23 6:08 AM, Dan Jacobson wrote:
>> It's not fair:
>> set -x a b c
>> m=$@ n=($@)
>> == gives ==
>> + m='a b c'
>> + n=($@)

CR> It's because the compound assignment forces the expansion to be deferred.
CR> You have to figure out what kind of array you're dealing with, for example,
CR> and what kind of compound assignment, and bash figures all that out after
CR> the `we're performing a variable assignment with xtrace enabled, print the
CR> rhs' code runs.