Re: whats wrong , exit code 11 on android termux
On 8/9/24 10:01 PM, Martin D Kealey wrote: On Thu, 8 Aug 2024 at 03:14, alex xmb sw ratchev wrote: mr chet I REALLY get annoyed when strangers call me "Mister Martin" or write "Mr Martin". I am NOT a child, so how DARE they mock me like that. The short version: Some folk don't care, others don't know any better, but if you suspect the person you're talking to is over 40, I would strongly recommend you avoid this style of address - unless of course you WANT to mock them. I'm always amazed at the human capacity to take offense. Of course, I'm on social media, so it shouldn't surprise me. Anyway, take a breath, maybe go out and touch grass. It was me he was addressing, and I don't feel mocked. And I'm well over 40. -- ``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: whats wrong , exit code 11 on android termux
On 8/9/24 11:02 PM, Oğuz wrote: On Saturday, August 10, 2024, Martin D Kealey wrote: Sorry, that was supposed to be a personal reply off-list. Do you always harass foreigners like that or was it an exception? "Foreigner" is indeed tricky in this context. I'd guess that the four principals in this little sub-discussion (including Alex) are from four different countries, if not four different continents. -- ``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
printf inconsistent results for %.0f
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall uname output: Linux p14s 6.9.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.12-1 (2024-07-27) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 21 Release Status: release Description: One of my old script that's been in use for 10+ years is using built-in bash printf for rounding float value to int via `printf`; as of today (Aug 12) it started returning erroneous and inconsistent results. Note it doesn't require float input value - trying to format full integers reproduces the problem the same. Bash version hasn't been updated for ages so assuming it has to be a dependency issue. Repeat-By: Small sample size of rounding `239.99040` to nearest int: ``` $ printf '%.0f' '239.99040' 0 $ printf '%.0f' '239.99040' 0 $ printf '%.0f' '239.99040' -0 $ printf '%.0f' '239.99040' -27846927597791718682626485772264082260943151763250104531...(trunc) $ printf '%.0f' '239.99040' -5226531939273184317269837678121820405198708758590818...(trunc) $ printf '%.0f' '239.99040' -0 $ printf '%.0f' '239.99040' -51368514663558334697487160651500630134194851172568251199...(trunc) ```
Re: printf inconsistent results for %.0f
On Mon, Aug 12, 2024 at 16:30:26 +0200, Laur Aliste wrote: > Configuration Information: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-protection -Wall > uname output: Linux p14s 6.9.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 6.9.12-1 (2024-07-27) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 > Patch Level: 21 > Release Status: release > > Description: > One of my old script that's been in use for 10+ years is using > built-in bash printf > for rounding float value to int via `printf`; as of today (Aug 12) > it started > returning erroneous and inconsistent results. Arch Linux, by any chance? https://lists.gnu.org/archive/html/bug-bash/2024-07/msg00034.html https://gitlab.archlinux.org/archlinux/packaging/packages/bash/-/issues/3
Re: printf inconsistent results for %.0f
On 8/12/24 10:30 AM, Laur Aliste wrote:
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
One of my old script that's been in use for 10+ years is using
built-in bash printf
for rounding float value to int via `printf`; as of today (Aug 12)
it started
returning erroneous and inconsistent results.
Note it doesn't require float input value - trying to format full integers
reproduces the problem the same.
It's probably a bug with configure, which a gcc update has triggered.
I've attached a patch.
Bash version hasn't been updated for ages so assuming it has to be
a dependency issue.
My question is why the (admittedly old) gnulib replacement strtod/strtold
is messing things up.
--
``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-20231106/configure.ac Fri Aug 11 14:52:31 2023
--- configure.acTue Nov 21 12:00:25 2023
***
*** 899,903
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
--- 900,904
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, *bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
*** ../bash-20231106/configure Fri Aug 18 16:27:53 2023
--- configure Tue Nov 21 12:00:30 2023
***
*** 15923,15927
main (void)
{
! long double r; char *foo, bar; r = strtold(foo, &bar);
;
--- 15932,15936
main (void)
{
! long double r; char *foo, *bar; r = strtold(foo, &bar);
;
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/7/24 2:47 PM, Zachary Santer wrote: On Wed, Aug 7, 2024 at 11:06 AM Chet Ramey wrote: On 7/31/24 11:40 AM, Zachary Santer wrote: I think I was missing more than that. Was the original 'wait -n' discussion from January specific to its use within the interactive shell? No, it was due to processes exiting due to signals. But you could have looked that up yourself. That was a big discussion, and I wasn't a part of it. Let's not miss my point, though. The "next" in the description of 'wait -n' in the manual currently means different things depending on if you're in a script or in the interactive shell, at least given the testing of bash-5.3-alpha that I performed. In a script, 'wait -n' without id arguments doesn't appear to skip child processes that have already terminated. This is good. In the interactive shell, it does. That stuff changed last month, after bash-5.3-alpha was released. Before that change, neither interactive nor non-interactive shells checked the list of saved statuses. The difference was when the user was notified of a process's exit status and when a job was removed from the jobs list. -- ``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: 'wait -n' with and without id arguments
On 8/7/24 2:47 PM, Zachary Santer wrote: Now I understand that this is because the list of terminated child processes that 'wait -n' currently ignores is only used in the interactive shell. Do you mean when no arguments are supplied? It's not. The difference is when a job is marked as notified and eligible to be removed from the jobs list. If you want the behavior of 'wait -n' to be consistent between scripts and the interactive shell, then it should choose one terminated child process from the list of those that is maintained in the interactive shell, if it's nonempty, to report to the user and to clear from that list, any time it is called. That would make it different from wait without -n. -- ``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: 'wait -n' with and without id arguments
On Mon, Aug 12, 2024 at 11:12 AM Chet Ramey wrote: > > That stuff changed last month, after bash-5.3-alpha was released. Before > that change, neither interactive nor non-interactive shells checked the > list of saved statuses. The difference was when the user was notified of > a process's exit status and when a job was removed from the jobs list. Not sure I want to commit myself to spinning up a RHEL 9 VM just to keep this conversation moving, Nobody had any answers in my help-bash thread on this topic, but does the devel branch have any build dependency that differs from those of the master and pre-release branches?
Re: 'wait -n' with and without id arguments
On Mon, Aug 12, 2024 at 11:13 AM Chet Ramey wrote: > > On 8/7/24 2:47 PM, Zachary Santer wrote: > > > Now I understand that this is because the list of terminated child > > processes that 'wait -n' currently ignores is only used in the > > interactive shell. > > Do you mean when no arguments are supplied? Yeah, trying to avoid repeating myself too much. > It's not. The difference is > when a job is marked as notified and eligible to be removed from the > jobs list. > > > If you want the behavior of 'wait -n' to be > > consistent between scripts and the interactive shell, then it should > > choose one terminated child process from the list of those that is > > maintained in the interactive shell, if it's nonempty, to report to > > the user and to clear from that list, any time it is called. > > That would make it different from wait without -n. And that's fine. Why would you consider that a problem?
Re: word selection in history expansion - !?word?%
On 8/9/24 2:15 AM, Jess M wrote: Observed behaviour: ``` $ echo word01 word02 word03 floogle word01 word02 word03 floogle $ echo !?word?% echo word03 word03 $ # I expected to get word01 $ echo $BASH_VERSION 5.2.26(1)-release ``` The bash manual for word designators sounds to me as if word01 should be selected. That's certainly the csh behavior. Bash has done it this way for as long as its history expansion has been implemented. It dates back to at least 1988-89. I think the idea (that was a long time ago) was that it started as a way to perform searching for readline, and in that case you want the history to basically be treated as a single long string, in which you search backwards or forwards from the current location. The csh-style history expansion code inherited that behavior. It should not be difficult to provide an option to do it the csh way, but there's a lot of existing behavior there, so I don't know about making it the default. -- ``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: word selection in history expansion - !?word?%
Given the age of the behaviour, I would agree on not making it the default
behaviour.
To update the documentation to reflect that, how about something like this:
--- current --- lib/readline/doc/hsuser.texi
@item %
The first word matched by the most recent @samp{?@var{string}?} search,
if the search string begins with a character that is part of a word.
--- proposed ---
@item %
The first word matched by the most recent @samp{?@var{string}?} search,
if the search string begins with a character that is part of a word. The
search happens in reverse, so if multiple words on a line match, the word
nearer the end of the line is returned.
---
As for providing an option to alter the search behaviour:
The initial surprise was that a forward-line search should happen (rather
than the observed reverse line search). In practice, just having a firm
understanding of the exact behaviour, is enough for my needs, I can
compensate my usage accordingly. The option to to change the search
direction feels rather limited. If the code is to be updated, I'd look for
something more flexible.
Consider updating the word designator to accept a count. In this mode,
`!?word?:%3` would provide the third found item found in a reverse search.
Example:
```
$ echo example-line01-word01 example-line01-word02
example-line01-word01 example-line01-word02
$ echo example-line02-word01 example-line02-word02
example-line02-word01 example-line02-word02
$ echo !?example?:%2
echo example-line02-word01
example-line02-word01
```
A consideration would be how to handle multiple lines.
We could error:
```
$ echo example-line01-word01 example-line01-word02
example-line01-word01 example-line01-word02
$ echo example-line02-word01 example-line02-word02
example-line02-word01 example-line02-word02
$ echo !?example?:%3
bash: !?example?:%3: event not found
```
Alternatively, we could look on previous lines
```
$ echo example-line01-word01 example-line01-word02
example-line01-word01 example-line01-word02
$ echo example-line02-word01 example-line02-word02
example-line02-word01 example-line02-word02
$ echo !?example?:%3
echo example-line01-word02
example-line01-word02
```
As there are not three matches on the first found line, we continue
counting across previous lines.
Implementing the search across lines might prove tricky. The current code
splits line match and word match; we don't even count words until after
we've identified the matched line.
-- Jess M
On Mon, Aug 12, 2024 at 12:43 PM Chet Ramey wrote:
> On 8/9/24 2:15 AM, Jess M wrote:
> > Observed behaviour:
> > ```
> > $ echo word01 word02 word03 floogle
> > word01 word02 word03 floogle
> > $ echo !?word?%
> > echo word03
> > word03
> > $ # I expected to get word01
> > $ echo $BASH_VERSION
> > 5.2.26(1)-release
> > ```
> >
> > The bash manual for word designators sounds to me as if word01 should be
> > selected.
>
> That's certainly the csh behavior.
>
> Bash has done it this way for as long as its history expansion has been
> implemented. It dates back to at least 1988-89. I think the idea (that
> was a long time ago) was that it started as a way to perform searching for
> readline, and in that case you want the history to basically be treated as
> a single long string, in which you search backwards or forwards from the
> current location. The csh-style history expansion code inherited that
> behavior.
>
> It should not be difficult to provide an option to do it the csh way, but
> there's a lot of existing behavior there, so I don't know about making it
> the default.
>
> --
> ``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/
>
termios.h not included if sys/ioctl.h provides struct winsize
On e.g. Alpine Linux, the following are set by configure: bash_cv_struct_winsize_ioctl='yes' bash_cv_struct_winsize_termios='yes' bash_cv_struct_winsize_header='ioctl_h' ac_cv_func_tcgetwinsize='yes' and so config.h ends up with: #define STRUCT_WINSIZE_IN_SYS_IOCTL 1 /* #undef STRUCT_WINSIZE_IN_TERMIOS */ #define HAVE_TCGETWINSIZE 1 This causes termios.h to not get included by lib/sh/winsize.c: #if defined (STRUCT_WINSIZE_IN_TERMIOS) && !defined (STRUCT_WINSIZE_IN_SYS_IOCTL) # include #endif and a build failure: winsize.c:95:20: error: call to undeclared function 'tcgetwinsize'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 95 | if (tty >= 0 && (tcgetwinsize (tty, &win) == 0) && win.ws_row > 0 && win.ws_col > 0) |^
