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/

bash-4.3 and ulimit -T

[William Bader]

I am running bash 4.3.33 that I built from source on Fedora 20 
3.18.7-100.fc20.x86_64.
When I run "help ulimit", the line for "-Tthe maximum number of threads" 
does not line up with the other options because the message in ulimit_doc[] 
around line 1443 of ulimit.c has 4 spaces after the -T instead of a tab.  Line 
53 of ulimit.def also has spaces instead of a tab.
Fixing this would also require fixing the string in the various *.po files.
ulimit on Fedora 20 does not implement -T, but could ulimit show the maximum 
number of CPUs, similar to "grep allowed /proc/self/status" or the taskset 
command?
William