Re: RFC: changing printf(1) behavior on %b

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 simil

Re: RFC: changing printf(1) behavior on %b

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?

Re: RFC: changing printf(1) behavior on %b

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 pri

Re: give_terminal_to() / maybe_give_terminal_to() race

On 2023-08-30 07:39, Chet Ramey wrote: OK, so there is a potential race condition here. What do you suggest the right approach might be? It seems to me we can do one of two things: rearrange and extend the PGRP_PIPE code to make sure the child process doesn't proceed until the parent sets the ter

Re: RFC: changing printf(1) behavior on %b

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 abo

Re: RFC: changing printf(1) behavior on %b

On Thu, Aug 31, 2023 at 9:11 PM Chet Ramey 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 least > has a passing resemblence to the desired functionality. > > Why not sta

Re: Inner Command Lists fail in Bash 5.2.15

On Thu, 31 Aug 2023 12:05:21 -0400 (EDT) dkro...@gmail.com wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: darwin20.6.0 > Compiler: clang > Compilation CFLAGS: -DSSH_SOURCE_BASHRC > uname output: Darwin San-Francisco-iMac.local 20.6.0 Darwin Ker

riscv32, qemu-user: semi-functional, what goes wrong?

Dear all, I'm trying to get qemu usermode emulation of riscv32 working. I managed to cross-build a linux system, and have it mostly rebuild itself (including gcc 3-phase bootstrap), however, something is broken in bash. Which may very well be a qemu usermode emulation bug, as I'm told bash works

Inner Command Lists fail in Bash 5.2.15

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin20.6.0 Compiler: clang Compilation CFLAGS: -DSSH_SOURCE_BASHRC uname output: Darwin San-Francisco-iMac.local 20.6.0 Darwin Kernel Version 20.6.0: Thu Jul 6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.12

Inner Command Groups fail in Bash 5.2

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin20.6.0 Compiler: clang Compilation CFLAGS: -DSSH_SOURCE_BASHRC uname output: Darwin San-Francisco-iMac.local 20.6.0 Darwin Kernel Version 20.6.0: Thu Jul  6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.1

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

On Thu, Aug 31, 2023 at 04:01:17PM -0500, Rob Landley wrote: > On 8/31/23 13: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. > > I.E. you sent an RFC t

Re: bug#65659: RFC: changing printf(1) behavior on %b

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

Re: bug#65659: RFC: changing printf(1) behavior on %b

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

Re: bug attached

yes ! the local declaration solved my problem. tnx very much . On Thu, Aug 31, 2023 at 10:51 PM Andreas Kusalananda Kähäri < andreas.kah...@abc.se> wrote: > On Thu, Aug 31, 2023 at 10:38:55PM +0300, queency3 jones wrote: > > i don't think that main is significant when it declared in "Bash" but >

Re: bug attached

On Thu, Aug 31, 2023 at 10:38:55PM +0300, queency3 jones wrote: > i don't think that main is significant when it declared in "Bash" but even > though, > if you change the function main , to function ain the $aa should be local > , but it ain't !! Function names being "main" or "ain" is irrelevant

Re: bug attached

On Thu, Aug 31, 2023 at 10:38:55PM +0300, queency3 jones wrote: > > > function sub { aa=8;return_value=$aa; } > > > function sub { aa=8; } > > > > > > function main { aa=3;sub;aa=$(($aa+1));printf "$aa\n"; } > i don't think that main is significant when it declared in "Bash" but even > though, > i

Re: bug attached

On 8/31/23 3:38 PM, queency3 jones wrote: i don't think that main is significant when it declared in "Bash" but even though, if you change the function main , to function ain the $aa should be local , but it ain't !! Why? Are you saying that all variable assignments in functions should act as

Re: bug attached

i don't think that main is significant when it declared in "Bash" but even though, if you change the function main , to function ain the $aa should be local , but it ain't !! On Wed, Aug 30, 2023 at 5:59 PM Andreas Kusalananda Kähäri < andreas.kah...@abc.se> wrote: > On Wed, Aug 30, 2023 at 03:

Re: bug#65659: RFC: changing printf(1) behavior on %b

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 e

Re: RFC: changing printf(1) behavior on %b

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

Re: Some incorrect behaviour for BASH arrays

On Thu, Aug 31, 2023 at 04:13:09PM +0100, Kerin Millar wrote: > This script is a mess because its functions begin by defining RESULT as an > ordinary, non-array variable (if not yet declared). > > $ RESULT='string' > $ declare -p RESULT # not yet an array variable > declare -- RESULT='string' >

RFC: changing printf(1) behavior on %b

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 th

Re: Some incorrect behaviour for BASH arrays

On Thu, 31 Aug 2023 01:12:48 +0700 Victor Pasko wrote: > Hi, > > On my Win-7 64-bit using Cygwin > > > *% bash --version*GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin) > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later

Re: Some incorrect behaviour for BASH arrays

On Thu, 31 Aug 2023 19:39:09 +0700 Victor Pasko wrote: > Thanks for prompt response. But see my comments below. > > Well, instead of the following line > > RESULT='' > > done > > declare -p RESULT > > without initialization, because otherwise I got the following error "-bash: > declare: RESU

Re: Some incorrect behaviour for BASH arrays

Thanks for prompt response. But see my comments below. Well, instead of the following line RESULT='' done declare -p RESULT without initialization, because otherwise I got the following error "-bash: declare: RESULT=: not found". And after deleting/commenting the following fragment in badrev