Re: Bash 5.2: broken built-in printf for float numbers

[Greg Wooledge]

On Thu, Nov 07, 2024 at 10:16:46 +0100, Thomas Dreibholz wrote:
> Hi,
> 
> Bash 5.2 has a broken built-in printf for float numbers.
> 
> Example: printf "%5.1f" 1024 should print "1024.0" (with standard locale
> LC_ALL=C.UTF-8)
> 
> Testing the Bash shell in different versions of recent Debian and Ubuntu
> setups, the output is wrong. Bug tracker for Debian:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081424 .Depending on the
> Debian/Ubuntu patch version of Bash, the output made by Bash is either
> complete garbage (random), or "nan" or "-0.0". The output of the external
> command /usr/bin/printf is always correct.

The bug report you linked to says "Debian 11 and Debian 12 are fine"
and that the problem is only in Debian's "testing" and "unstable"
releases.

What you're seeing is a known bug that's triggered by some newer
compilers.  See

for details.

The bug is fixed in 
so you might want to inform the Debian people that this patch should
be applied.

Re: fg via keybind modifies tty settings

[Chet Ramey]

On 11/5/24 1:21 AM, David Moberg wrote:



Den ons 16 okt. 2024 17:43Chet Ramey > skrev:


On 10/13/24 12:10 PM, David Moberg wrote:
 > A new issue popped up with these changes. After second time of
suspend and
 > foreground with binding, the tty will not react to control keys but
instead
 > print them on the prompt.

In general, this can't work, given a well-behaved process like vim that
modifies the tty settings.

 > | start vim
 >    ctrl-z (to suspend)
 >    ctrl-a (bound to `fg` to bring to foregound)
 >    ctrl-z (to suspend a 2nd time)
 >    # broken state (but I dont see anything changed in the output of
`stty
 > -a`)
 >    # ctrl-a prints ^A (instead of executing fg)
 >    #  prints ^[[A (Instead of invoking history)
 >
 > Issue 1: control codes are printed to prompt

The important thing to remember is that the shell saves the tty settings
when it starts up and after each forked command exits, so it can set them
for child processes. This is how it can make stty settings stick while
still setting the terminal for readline. It doesn't do this if it's running
a command from a readline key binding.

It restores the terminal attributes to these saved settings after a process
exits due to a signal or stops so a misbehaving process doesn't corrupt
the terminal.

Let's use the following shorthand:

R = tty settings for readline (-icanon)
V = tty settings for vim (-icanon)
S = tty settings shell inherited or saved (icanon)

Here's what happens:

shell saves tty settings S
readline sets tty settings R
readline reads "vim ...\n"
shell sets tty to S
shell execs vim
vim saves tty settings S

vim sets tty settings V
vim reads ^Z
vim sets tty settings S (saved)

vim sends itself SIGTSTP
shell catches stopped child

shell sets tty settings S (the saved tty settings because the process
stopped)
readline sets tty settings R
readline reads ^A
shell sends SIGCONT due to running `fg' from the `bind -x' binding
         - this is where the shell used to save the terminal settings again
           for later resetting, but it no longer does due to your previous
           report, so S is unchanged

vim gets SIGCONT
vim sets tty settings V
vim reads ^Z
vim sets tty settings S (saved)

vim sends itself SIGTSTP
shell catches stopped child

shell sets tty settings S (saved tty settings because the process stopped)
         - but it wouldn't matter because vim already set them to S

readline is still active because this was all a key binding

Now readline thinks the settings are R, but the settings are S.





So there is no good way of solving this and therefor no way to solve it at all?


The bind -x execution code could restore the terminal settings to icanon
mode before executing the command, and then set them back to what readline
is using (-icanon) before returning. This is not backwards compatible
and would break all the bind -x bindings that assume the terminal is the
way readline set it, so I'm not inclined to do it.

I guess fish and zsh might be misbehaving in other ways, but they seem to 
handle this detail better. I wonder what the tradeoff is.


Historically, zsh doesn't let child processes change the terminal
settings at all. Look at the `ttyctl' builtin. I don't know what fish
does.


--
``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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

[Chet Ramey]

On 11/6/24 9:38 PM, David Linden wrote:


Bash Version: 4.4
Patch Level: 20
Release Status: release

Description:
This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo 
${#foo[@]}


Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
until it's been assigned a value. This fix aligns the array variable
behavior with the scalar (non-array) variable behavior.



How am I supposed to determine that a declared associative array is 
empty?


That's not the question that `set -u' answers. It will tell you whether
a variable with attributes (or without) has been assigned a value.

Does your code manage this variable? If it does, you should be able to
determine whether or not it was ever assigned a value, or make sure
that it has been assigned a value, if that's important. The empty array
is a valid value, just like the empty string is a valid value for scalar
variables.


Or even use it in a conditional even one where the value won't be 
evaluated?


What do you mean? Using something like foo[@] is fine in expansions
where it won't be expanded:

echo ${foo[@]-unset}

or

v=set; echo ${v:-foo[@]}

But if you get into a case where the variable needs to be expanded,
you're going to get an error if the variable isn't set.

--
``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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

[#!microsuxx]

On Thu, Nov 7, 2024, 21:10 Chet Ramey  wrote:

> On 11/6/24 9:38 PM, David Linden wrote:
>
> > Bash Version: 4.4
> > Patch Level: 20
> > Release Status: release
> >
> > Description:
> >   This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
> ${#foo[@]}
>
> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
> until it's been assigned a value. This fix aligns the array variable
> behavior with the scalar (non-array) variable behavior.
>
>
> >   How am I supposed to determine that a declared associative array
> is empty?
>

to try to answer ' how to check if assoc arr is empty '
first [[ ${name@a} == *A* ]] or == A not sure

then in code

~/m $ cat m.test.emptyassoc
#!/bin/bash

 c() {
local r=$@
eval -- "$r"
l
 }

 l() {
l1
 }

 r() {
eval "$@" &&
echo -e "$@\t\t$r"
  }

 l1() {
r [[ -v $n ]]
r "(( \${#$n[@]} ))"
 }

unset -v assoc n
n=assoc

c : init
c declare -A assoc
c 'assoc+=( foo bar )'
c 'assoc+=( 2foo 2bar )'
c unset -v $n

~/m $ bash m.test.emptyassoc
[[ -v assoc ]]  assoc+=( foo bar )
(( ${#assoc[@]} ))  assoc+=( foo bar )
[[ -v assoc ]]  assoc+=( 2foo 2bar )
(( ${#assoc[@]} ))  assoc+=( 2foo 2bar )

therefore [[ -v and (( $# works

That's not the question that `set -u' answers. It will tell you whether
> a variable with attributes (or without) has been assigned a value.
>
> Does your code manage this variable? If it does, you should be able to
> determine whether or not it was ever assigned a value, or make sure
> that it has been assigned a value, if that's important. The empty array
> is a valid value, just like the empty string is a valid value for scalar
> variables.
>
> >   Or even use it in a conditional even one where the value won't be
> evaluated?
>

what

What do you mean? Using something like foo[@] is fine in expansions
> where it won't be expanded:
>
> echo ${foo[@]-unset}
>
> or
>
> v=set; echo ${v:-foo[@]}
>
> But if you get into a case where the variable needs to be expanded,
> you're going to get an error if the variable isn't set.
>
> --
> ``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: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

[#!microsuxx]

On Thu, Nov 7, 2024, 23:36 #!microsuxx  wrote:

>
>
> On Thu, Nov 7, 2024, 21:10 Chet Ramey  wrote:
>
>> On 11/6/24 9:38 PM, David Linden wrote:
>>
>> > Bash Version: 4.4
>> > Patch Level: 20
>> > Release Status: release
>> >
>> > Description:
>> >   This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
>> ${#foo[@]}
>>
>> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
>> until it's been assigned a value. This fix aligns the array variable
>> behavior with the scalar (non-array) variable behavior.
>>
>>
>> >   How am I supposed to determine that a declared associative array
>> is empty?
>>
>
> to try to answer ' how to check if assoc arr is empty '
> first [[ ${name@a} == *A* ]] or == A not sure
>
> then in code
>
> ~/m $ cat m.test.emptyassoc
> #!/bin/bash
>
>  c() {
> local r=$@
> eval -- "$r"
> l
>  }
>
>  l() {
> l1
>  }
>
>  r() {
> eval "$@" &&
> echo -e "$@\t\t$r"
>   }
>
>  l1() {
> r [[ -v $n ]]
> r "(( \${#$n[@]} ))"
>  }
>
> unset -v assoc n
> n=assoc
>
> c : init
> c declare -A assoc
> c 'assoc+=( foo bar )'
> c 'assoc+=( 2foo 2bar )'
> c unset -v $n
>
> ~/m $ bash m.test.emptyassoc
> [[ -v assoc ]]  assoc+=( foo bar )
> (( ${#assoc[@]} ))  assoc+=( foo bar )
> [[ -v assoc ]]  assoc+=( 2foo 2bar )
> (( ${#assoc[@]} ))  assoc+=( 2foo 2bar )
>
> therefore [[ -v and (( $# works
>
> That's not the question that `set -u' answers. It will tell you whether
>> a variable with attributes (or without) has been assigned a value.
>>
>> Does your code manage this variable? If it does, you should be able to
>> determine whether or not it was ever assigned a value, or make sure
>> that it has been assigned a value, if that's important. The empty array
>> is a valid value, just like the empty string is a valid value for scalar
>> variables.
>>
>> >   Or even use it in a conditional even one where the value won't be
>> evaluated?
>
>
[[ -v assoc[\$elem] ]] if set , not checked if empty or not
else
[[ ${assoc[$elem]} ]]

what
>
> What do you mean? Using something like foo[@] is fine in expansions
>> where it won't be expanded:
>>
>> echo ${foo[@]-unset}
>>
>> or
>>
>> v=set; echo ${v:-foo[@]}
>>
>> But if you get into a case where the variable needs to be expanded,
>> you're going to get an error if the variable isn't set.
>>
>> --
>> ``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: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

[#!microsuxx]

sorry code cleaned up : it was more and stuff

 c() {
eval -- "$@"
l
 }

 l() {
r [[ -v $n ]]
r "(( \${#$n[@]} ))"
 }

 r() {
eval "$@" &&
echo -e "$@\t\t$r"
  }

c unset -v assoc
c declare -A assoc
c 'assoc+=( foo bar )'
c 'assoc+=( 2foo 2bar )'
c unset -v assoc

On Thu, Nov 7, 2024, 23:36 #!microsuxx  wrote:

>
>
> On Thu, Nov 7, 2024, 21:10 Chet Ramey  wrote:
>
>> On 11/6/24 9:38 PM, David Linden wrote:
>>
>> > Bash Version: 4.4
>> > Patch Level: 20
>> > Release Status: release
>> >
>> > Description:
>> >   This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
>> ${#foo[@]}
>>
>> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
>> until it's been assigned a value. This fix aligns the array variable
>> behavior with the scalar (non-array) variable behavior.
>>
>>
>> >   How am I supposed to determine that a declared associative array
>> is empty?
>>
>
> to try to answer ' how to check if assoc arr is empty '
> first [[ ${name@a} == *A* ]] or == A not sure
>
> then in code
>
> ~/m $ cat m.test.emptyassoc
> #!/bin/bash
>
>  c() {
> local r=$@
> eval -- "$r"
> l
>  }
>
>  l() {
> l1
>  }
>
>  r() {
> eval "$@" &&
> echo -e "$@\t\t$r"
>   }
>
>  l1() {
> r [[ -v $n ]]
> r "(( \${#$n[@]} ))"
>  }
>
> unset -v assoc n
> n=assoc
>
> c : init
> c declare -A assoc
> c 'assoc+=( foo bar )'
> c 'assoc+=( 2foo 2bar )'
> c unset -v $n
>
> ~/m $ bash m.test.emptyassoc
> [[ -v assoc ]]  assoc+=( foo bar )
> (( ${#assoc[@]} ))  assoc+=( foo bar )
> [[ -v assoc ]]  assoc+=( 2foo 2bar )
> (( ${#assoc[@]} ))  assoc+=( 2foo 2bar )
>
> therefore [[ -v and (( $# works
>
> That's not the question that `set -u' answers. It will tell you whether
>> a variable with attributes (or without) has been assigned a value.
>>
>> Does your code manage this variable? If it does, you should be able to
>> determine whether or not it was ever assigned a value, or make sure
>> that it has been assigned a value, if that's important. The empty array
>> is a valid value, just like the empty string is a valid value for scalar
>> variables.
>>
>> >   Or even use it in a conditional even one where the value won't be
>> evaluated?
>>
>
> what
>
> What do you mean? Using something like foo[@] is fine in expansions
>> where it won't be expanded:
>>
>> echo ${foo[@]-unset}
>>
>> or
>>
>> v=set; echo ${v:-foo[@]}
>>
>> But if you get into a case where the variable needs to be expanded,
>> you're going to get an error if the variable isn't set.
>>
>> --
>> ``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: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

[#!microsuxx]

there is still code fault $n is supposed to be 'assoc' im sorry bye

On Thu, Nov 7, 2024, 23:44 #!microsuxx  wrote:

> sorry code cleaned up : it was more and stuff
>
>  c() {
> eval -- "$@"
> l
>  }
>
>  l() {
> r [[ -v $n ]]
> r "(( \${#$n[@]} ))"
>  }
>
>  r() {
> eval "$@" &&
> echo -e "$@\t\t$r"
>   }
>
> c unset -v assoc
> c declare -A assoc
> c 'assoc+=( foo bar )'
> c 'assoc+=( 2foo 2bar )'
> c unset -v assoc
>
> On Thu, Nov 7, 2024, 23:36 #!microsuxx  wrote:
>
>>
>>
>> On Thu, Nov 7, 2024, 21:10 Chet Ramey  wrote:
>>
>>> On 11/6/24 9:38 PM, David Linden wrote:
>>>
>>> > Bash Version: 4.4
>>> > Patch Level: 20
>>> > Release Status: release
>>> >
>>> > Description:
>>> >   This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo
>>> ${#foo[@]}
>>>
>>> Yes, this was a bug in bash-4.2, fixed in bash-4.3. A variable isn't set
>>> until it's been assigned a value. This fix aligns the array variable
>>> behavior with the scalar (non-array) variable behavior.
>>>
>>>
>>> >   How am I supposed to determine that a declared associative array
>>> is empty?
>>>
>>
>> to try to answer ' how to check if assoc arr is empty '
>> first [[ ${name@a} == *A* ]] or == A not sure
>>
>> then in code
>>
>> ~/m $ cat m.test.emptyassoc
>> #!/bin/bash
>>
>>  c() {
>> local r=$@
>> eval -- "$r"
>> l
>>  }
>>
>>  l() {
>> l1
>>  }
>>
>>  r() {
>> eval "$@" &&
>> echo -e "$@\t\t$r"
>>   }
>>
>>  l1() {
>> r [[ -v $n ]]
>> r "(( \${#$n[@]} ))"
>>  }
>>
>> unset -v assoc n
>> n=assoc
>>
>> c : init
>> c declare -A assoc
>> c 'assoc+=( foo bar )'
>> c 'assoc+=( 2foo 2bar )'
>> c unset -v $n
>>
>> ~/m $ bash m.test.emptyassoc
>> [[ -v assoc ]]  assoc+=( foo bar )
>> (( ${#assoc[@]} ))  assoc+=( foo bar )
>> [[ -v assoc ]]  assoc+=( 2foo 2bar )
>> (( ${#assoc[@]} ))  assoc+=( 2foo 2bar )
>>
>> therefore [[ -v and (( $# works
>>
>> That's not the question that `set -u' answers. It will tell you whether
>>> a variable with attributes (or without) has been assigned a value.
>>>
>>> Does your code manage this variable? If it does, you should be able to
>>> determine whether or not it was ever assigned a value, or make sure
>>> that it has been assigned a value, if that's important. The empty array
>>> is a valid value, just like the empty string is a valid value for scalar
>>> variables.
>>>
>>> >   Or even use it in a conditional even one where the value won't
>>> be evaluated?
>>>
>>
>> what
>>
>> What do you mean? Using something like foo[@] is fine in expansions
>>> where it won't be expanded:
>>>
>>> echo ${foo[@]-unset}
>>>
>>> or
>>>
>>> v=set; echo ${v:-foo[@]}
>>>
>>> But if you get into a case where the variable needs to be expanded,
>>> you're going to get an error if the variable isn't set.
>>>
>>> --
>>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>>  ``Ars longa, vita brevis'' - Hippocrates
>>> Chet Ramey, UTech, CWRUc...@case.edu
>>> http://tiswww.cwru.edu/~chet/
>>>
>>

Re: Bash 5.2: broken built-in printf for float numbers

[Chet Ramey]

On 11/7/24 4:16 AM, Thomas Dreibholz wrote:

Hi,

Bash 5.2 has a broken built-in printf for float numbers.


https://lists.gnu.org/archive/html/bug-bash/2024-09/msg00094.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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] lib/readline/doc makefiles clean targets

[Chet Ramey]

On 11/4/24 9:44 AM, Mike Jonkmans wrote:


According to info (make)Standard Targets, we should have:
 mostlyclean < clean < distclean < maintainer-clean

That hierarchy isn't gospel.


Agreed, but...


The current Makefile rules are fine.


There are some issues though. Some less important.
1) After 'make distclean', it doesn't build: some .o files need y.tab.h.


y.tab.h isn't part of the devel branch, you need bison to build it, and
it is included in the bash distributions. I see the problem here, though.
I'll figure out a way to fix it that's compatible with it being included
and not without too many release-specific changes.

The fundamental difference is that the devel branch and the master
(distribution) branch contain different files, and serve different
purposes from a common source base, and the existing Makefiles are
built for the master branch. That's why, for instance, the distclean
target in doc/Makefile.in removes the texinfo intermediate files -- they
are not part of the distributions. They appear in the devel branch for
convenience. I don't think their presence makes it any less easy to work
with the devel branch, though.

If you find yourself in this sitution, it's easy enough to remove
parser-built and y.tab.c and run make again before I fix it.



2) The use of recursive make, makes it harder to do dependencies right;


It's the best way to build using optional components and subdirectories.
If you have missing dependencies, send them along.


2a) Building outside of the source tree does not have proper deps;


As above.


3) The various Makefiles disagree on 'clean: mostlyclean' versus
'mostlyclean: clean';


Is this substantive or just cosmetic?


4) .PHONY is not used for the sub-makes *clean rules;


You mean in the subdirectory makefiles?


5) git (status), .gitignore and make are disconnected;


What does this mean? There are a couple of files that I need to add
to .gitignore; is this something else?


6) There is redundancy/duplication in the actions of various rules;


OK.


6) Same for the definitions of variables.


Examples?


(One could argue, whether the devel branch is a distribution.)

It's not. It's a snapshot of ongoing work.


As such, it has the purpose of:
- bringing in early fixes/patches;
- communicating future changes, eliciting comments.


In many cases, yes. In some cases, I solicit discussion, usually here.



So the devel branch should be easy to work with for outsiders.


How would the standard make targets make it easier to work with (besides
fixing a couple of previously-discussed issues)? What are we doing here
beyond `configure; make' and testing out various behaviors?


That, in my opinion, would warrant more adherence to the
standard make targets.


Why?


It doesn't need to be religious,
perhaps stating deviations and/or documenting what the expectations
are on the various make-targets. INSTALL already has some text.


Are these `standard make targets' anything other than clean and
mostlyclean?



Are you often building from devel yourself? As maybe a check, in git,
on a push to devel, would be nice to have.


I always build the code I push to the devel branch from a clean tree
before I push it.



Anyway, I suppose that for the clean-targets (not maintainer-clean)
   git restore .; configure; make `clean-target'
should see no deleted/modified files in 'git status'.
This currently is not the case for mostlyclean and distclean.


Well, see above about the difference between the devel and master
branches.

There's a lot of stuff that's in the devel branch for convenience,
and some that's the opposite (y.tab.?). You can do some things with
.gitignore, but that's not enough for all the differences.

I do primarily build the devel branch in build directories different
from the source directory, and I always recommend doing that, so
maybe that masks some of the issues you're encountering.




Misc notes
- examples/loadables/Makefile(.in) has no mostlyclean target.
   The error is ignored, but clutters the output.


?

$ grep mostlyclean examples/loadables/Makefile.in
mostlyclean:clean


- 'make mostlyclean' removes doc/bashref.* and doc/Makefile.


It shouldn't remove the Makefile, and you can make it again, but I can't
reproduce it removing the bashref.* files.



   No recovery, must run 'git restore doc; configure'.
- in doc/Makefile: the maybe-clean test should use realpath (cd ...; pwd -P)


I already made that exact change, actually, to match Makefile.in.


--
``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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

"complete -o filenames" sometimes not working

[Clark Wang]

See the following reproduce example:

$ cat ssh_compspec
COMP_WORDBREAKS=${COMP_WORDBREAKS//[=:]/}

function _ssh()
{
local cur="$2" pre="$3"
local options=(
ProxyCommand='/usr/bin/nc -x host:port %h %p -X 5'
ProxyCommand='/usr/bin/nc -x host:port %h %p -X connect'
ConnectTimeout=10 )
local i saveIFS="$IFS"

if [[ $pre == '-o' ]]; then
for ((i=0; i < ${#options[@]}; ++i)); do
options[i]=$( printf '%q' "${options[i]}" )
done

IFS=$'\n'
COMPREPLY=( $( compgen -W "${options[*]}" -- "$cur" ) )
IFS=$saveIFS
fi
}

complete -F _ssh -o filenames ssh
$ . ./ssh_compspec

Then,

$ ssh -o 
ConnectTimeout=10 nc -x host:port %h %p -X 5nc -x
host:port %h %p -X connect

As we can see, "ProxyCommand" is missing.

But this works fine:

$ ssh -o P
$ ssh -o ProxyCommand=/usr/bin/nc\ -x\ host:port\ %h\ %p\ -X\

AW: Re: AW: Re: AW: Re: AW: Re: read command sometimes misses newline on timeout

[Thomas Oettli]

I can confirm that the patch resolves all the issues I had.
Thank you very much for your help, it is very appreciated.

On 10/15/24 11:08 AM, Thomas Oettli wrote:
> Got it, I just backported your patch to Bash 5.2 and it fixed the issue on
> my build host.
> I will roll out the patched version to all my hosts this weekend and keep
> you noticed if anything strange happens.
> BTW: will this patch be backported to previous Bash versions?

I doubt it; I have only done that once, for shellshock.

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

Bash 5.2: broken built-in printf for float numbers

[Thomas Dreibholz]

Hi,

Bash 5.2 has a broken built-in printf for float numbers.

Example: printf "%5.1f" 1024 should print "1024.0" (with standard locale 
LC_ALL=C.UTF-8)


Testing the Bash shell in different versions of recent Debian and Ubuntu 
setups, the output is wrong. Bug tracker for Debian: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081424 .Depending on 
the Debian/Ubuntu patch version of Bash, the output made by Bash is 
either complete garbage (random), or "nan" or "-0.0". The output of the 
external command /usr/bin/printf is always correct.


The attached small Bash script runs Docker with different Debian and 
Ubuntu containers, generating test output with version information. The 
generated output of ./bash-bug-test1 | tee bash-bug-test1.log is 
attached as well.


--
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===

Thu Nov  7 10:01:01 CET 2024

debian:buster:
Using /usr/bin/printf:  	1024.0 KiB
Version: 5.0-4
BASH_VERSION=5.0.3(1)-release
Before update, built-in:	1024.0 KiB
Version: 5.0-4
BASH_VERSION=5.0.3(1)-release
After update, built-in: 	1024.0 KiB

debian:bullseye:
Using /usr/bin/printf:  	1024.0 KiB
Version: 5.1-2+deb11u1
BASH_VERSION=5.1.4(1)-release
Before update, built-in:	1024.0 KiB
Version: 5.1-2+deb11u1
BASH_VERSION=5.1.4(1)-release
After update, built-in: 	1024.0 KiB

debian:bookworm:
Using /usr/bin/printf:  	1024.0 KiB
Version: 5.2.15-2+b7
BASH_VERSION=5.2.15(1)-release
Before update, built-in:	1024.0 KiB
Version: 5.2.15-2+b7
BASH_VERSION=5.2.15(1)-release
After update, built-in: 	1024.0 KiB

debian:trixie:
Using /usr/bin/printf:  	1024.0 KiB
Version: 5.2.32-1+b1
BASH_VERSION=5.2.32(1)-release
Before update, built-in:	 -0.0 KiB
Version: 5.2.32-1+b2
BASH_VERSION=5.2.32(1)-release
After update, built-in: 	 -0.0 KiB

debian:testing:
Using /usr/bin/printf:  	1024.0 KiB
Version: 5.2.32-1+b1
BASH_VERSION=5.2.32(1)-release
Before update, built-in:	  0.0 KiB
Version: 5.2.32-1+b2
BASH_VERSION=5.2.32(1)-release
After update, built-in: 	  0.0 KiB

debian:unstable:
Using /usr/bin/printf:  	1024.0 KiB
Version: 5.2.32-1+b1
BASH_VERSION=5.2.32(1)-release
Before update, built-in:	-20432774153898713253319279492741904610614437077236906714400196506516124204528985393342460303961074276577979381059780118475412927505336030961811096942323171738406243205842734782630748596976291469166433050997920003284204949195776429007878596275736935007691106996923972915473612927078576999273496097655501043071338361834078882078850755912931818920827245197726933263644420311432302239297308100565898479207086903984385828789814414981690749439332181582680542201717472564136221239753993851982190240238791541332089570557201885179890377302477002922124411517230531818054795401384223215189011935314293883916979145489846500506592635093432793722382919532295902806380857944892250963221794064152536807398023104613919406311786270941478144367649042243217122377295460420463810138083948786177943414844074677596160027862426449905657863597125961062105083028616954227291913778242133831731907502218388948072417032590458138121137342024504143758637220811328565530823581438964480188755048947898356649099930691259186081195164602190286564341407535079543282762268081027174996242400363408222787486337809357863877678425906623708788481377526576834663533050333808731370344736312297937570374555754943286491313803039512663246302460388956082197051967893404597746739346205344097546545056232525515110032545432823068791366272858969443338995149286303935506853866238878925263500364512767131297260850733787240238696323077482157194863885020387919938794252830077318453786092843973661107351310075294230335840417423315683219693833620368902457223854714623681934601788232781034406003977190353115167932320219711704911171204865452395636851559254942586338974595835308584578688092521233264138977206531807833792499638829996467940653654210926176966726520707032231212219333551738665175951909574819596325493557099342872407310443023960984277127629873149128973503969947969433455594254631461960031272464747661333191220507203272973317445246836423674118272289860430228711300344117279522278471627671916893603169201741405643709793434862974774025612017722051388939315928915507318254840866988776548497185952504335427945978314024780620445356172745999177824067769470102229828748713898544891266800791621459858729086808950060459269558357279162332001680577872407977523487295181118241119718129515772958947773415954