Re: proposed BASH_SOURCE_PATH

[konsolebox]

On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey  wrote:
>
> On 7/18/24 4:44 PM, konsolebox wrote:
> > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey  wrote:
> >>
> >> On 7/11/24 3:51 AM, konsolebox wrote:
> >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey  wrote:
>  and the BASH_SOURCE
>  absolute pathname discussion has been bananas, so that's not going in any
>  time soon.
> >>>
> >>> Maybe just create BASH_SOURCE_REAL instead to avoid the gripes.
> >>
> >> I don't think so. It's not very useful to have two variables that are so
> >> similar -- it's needless overhead.
> >
> > So I guess it's really now just about BASH_SOURCE.  What's the final
> > decision on this?  I don't think waiting for more input would make a
> > difference.
>
> The best path forward is to enable the behavior with a new shell option,
> initially disabled.

I just saw the new changes and tested it.  It's not useful because
BASH_SOURCE still expands to the relative form after `shopt -s
bash_source_fullpath` is executed in the main script. This is why I
was saying context directories would have to be stored and paths
already stored in BASH_SOURCE would have to be converted to real path
versions the moment the option is enabled; reason why I don't like it
being made optional.  BASH_SOURCE_REAL is still the most sensible
choice.

If this is already final can the option at least be allowed to be
enabled by default at compile time?

https://gist.github.com/konsolebox/9c500cc693c5e22859dc79b2750068a8#file-add-enable-bash-source-fullpath-default-configure-option-patch


-- 
konsolebox

Re: proposed BASH_SOURCE_PATH

[konsolebox]

On Tue, Aug 6, 2024 at 3:09 PM konsolebox  wrote:
>
> On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey  wrote:
> >
> > On 7/18/24 4:44 PM, konsolebox wrote:
> > > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey  wrote:
> > >>
> > >> On 7/11/24 3:51 AM, konsolebox wrote:
> > >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey  wrote:
> >  and the BASH_SOURCE
> >  absolute pathname discussion has been bananas, so that's not going in 
> >  any
> >  time soon.
> > >>>
> > >>> Maybe just create BASH_SOURCE_REAL instead to avoid the gripes.
> > >>
> > >> I don't think so. It's not very useful to have two variables that are so
> > >> similar -- it's needless overhead.
> > >
> > > So I guess it's really now just about BASH_SOURCE.  What's the final
> > > decision on this?  I don't think waiting for more input would make a
> > > difference.
> >
> > The best path forward is to enable the behavior with a new shell option,
> > initially disabled.
>
> I just saw the new changes and tested it.  It's not useful because
> BASH_SOURCE still expands to the relative form after `shopt -s
> bash_source_fullpath` is executed in the main script. This is why I
> was saying context directories would have to be stored and paths
> already stored in BASH_SOURCE would have to be converted to real path
> versions the moment the option is enabled; reason why I don't like it
> being made optional.  BASH_SOURCE_REAL is still the most sensible
> choice.
>
> If this is already final can the option at least be allowed to be
> enabled by default at compile time?
>
> https://gist.github.com/konsolebox/9c500cc693c5e22859dc79b2750068a8#file-add-enable-bash-source-fullpath-default-configure-option-patch

I also noticed before that sh_physpath allocates buffers using
PATH_MAX+1, so push_source and realpath_builtin probably should do it
as well.

https://gist.github.com/konsolebox/5af2358f98c761abda278000b69e6914#file-pathmax-plus-one-patch


-- 
konsolebox

return from trap while reading with readline breaks completion

[Oğuz]

See:

$ ls
foo  s
$ cat s
trap return INT
read -e
$ source s

I press Ctrl-C here and bash prompts me for the next command. Then I
press F and Tab; instead of producing the bell sound bash completes f
to foo. If I press Ctrl-C again it prints "bash: return: can only
`return' from a function or sourced script" and completion returns to
normal.

Oğuz

[bug #66068] built-in printf function not working with float

[anonymous]

URL:
  

 Summary: built-in printf function not working with float
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Tue 06 Aug 2024 09:58:54 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Tue 06 Aug 2024 09:58:54 AM UTC By: Anonymous
*Affected version: 5.2.32(1)*

jesusm@liet:[~]$ bash --version
GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2022 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.
jesusm@liet:[~]$ printf "%f\n" 1.2
-nan
jesusm@liet:[~]$ /bin/printf "%f\n" 1.2
1.20
jesusm@liet:[~]$


*Working version: 5.2.26(1)*

jesusm@liet:[~]$ bash --version
GNU bash, version 5.2.26(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2022 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.
jesusm@liet:[~]$ printf "%f\n" 1.2
1.20
jesusm@liet:[~]$ /bin/printf "%f\n" 1.2
1.20
jesusm@liet:[~]$









___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

Re: [bug #66068] built-in printf function not working with float

[Greg Wooledge]

On Tue, Aug 06, 2024 at 05:58:56 -0400, anonymous wrote:
> jesusm@liet:[~]$ bash --version
> GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu)
> Copyright (C) 2022 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.
> jesusm@liet:[~]$ printf "%f\n" 1.2
> -nan

For whatever it's worth, I can't duplicate this with upstream bash 5.2.32
compiled on Debian 12 amd64.  It might be a problem in the poster's libc,
the poster's compiler, or some Linux distribution's patches.

The poster might be using "x86_64-slackware-linux-gnu" as shown in
the output, but there's no way to contact them to get confirmation or
additional details (like "which version of Slackware").

Re: waiting for process substitutions

[Zachary Santer]

On Tue, Aug 6, 2024 at 1:19 AM Oğuz  wrote:
>
> The benefit is they're separate from async jobs and don't get in your way. 
> `wait' waiting for the last procsub is acceptable, `wait' waiting for a 
> procsub that I forgot about and that won't be listed by `jobs' is not.

I can not think of a time when I called 'wait' from the command line
that wasn't just for testing something. Even using process
substitutions on the command line is a relative rarity for me. If
we're balancing behavior on the command line against behavior in a
script, I think I'd give priority to scripting, at least here.

Chet doesn't see much value in making process substitutions jobs,
which I guess is fine. Can we agree that if they were made jobs,
though, waiting for all of them would be acceptable? You could see
them listed and handle them however you need.

> Procsubs occupying one slot in the shell's internal list of job statuses is 
> acceptable, them filling up that list and causing data loss/oom errors is not.

Bash is evidently already tracking all the procsub pids in their own
list, which now is always cleared when you call 'wait' without
arguments.

Re: waiting for process substitutions

[alex xmb sw ratchev]

On Tue, Aug 6, 2024, 13:59 Zachary Santer  wrote:

> On Tue, Aug 6, 2024 at 1:19 AM Oğuz  wrote:
> >
> > The benefit is they're separate from async jobs and don't get in your
> way. `wait' waiting for the last procsub is acceptable, `wait' waiting for
> a procsub that I forgot about and that won't be listed by `jobs' is not.
>
> I can not think of a time when I called 'wait' from the command line
> that wasn't just for testing something. Even using process
> substitutions on the command line is a relative rarity for me. If
> we're balancing behavior on the command line against behavior in a
> script, I think I'd give priority to scripting, at least here.
>
> Chet doesn't see much value in making process substitutions jobs,
> which I guess is fine. Can we agree that if they were made jobs,
> though, waiting for all of them would be acceptable? You could see
> them listed and handle them however you need.
>
> > Procsubs occupying one slot in the shell's internal list of job statuses
> is acceptable, them filling up that list and causing data loss/oom errors
> is not.
>
> Bash is evidently already tracking all the procsub pids in their own
> list, which now is always cleared when you call 'wait' without
> arguments.
>

where can i find this list

>

Re: waiting for process substitutions

[Oğuz]

On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer  wrote:
> I can not think of a time when I called 'wait' from the command line
> that wasn't just for testing something. Even using process
> substitutions on the command line is a relative rarity for me. If
> we're balancing behavior on the command line against behavior in a
> script, I think I'd give priority to scripting, at least here.

This belongs on your personal blog.

> Chet doesn't see much value in making process substitutions jobs,
> which I guess is fine. Can we agree that if they were made jobs,
> though, waiting for all of them would be acceptable? You could see
> them listed and handle them however you need.

Making them jobs would be a bad idea. There are two major use cases of
process substitutions:
1. Piping the output of a script to a command from within the script itself.
2. Creating one-off FIFO files in scripts and on the command line.
Neither use case would be improved if procsubs were made jobs. And
it'd create too much noise for miniscule benefit.

> Bash is evidently already tracking all the procsub pids in their own
> list, which now is always cleared when you call 'wait' without
> arguments.

It's okay as long as the user has his CHILD_MAX remembered jobs. If
too much memory is used for procsubs or if they stay in memory for too
long that should be fixed.

Re: [bug #66068] built-in printf function not working with float

[Chet Ramey]

On 8/6/24 5:58 AM, anonymous wrote:


jesusm@liet:[~]$ bash --version
GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2022 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.
jesusm@liet:[~]$ printf "%f\n" 1.2
-nan
jesusm@liet:[~]$ /bin/printf "%f\n" 1.2
1.20
jesusm@liet:[~]$


Nothing changed here between 5.2.26 and 5.2.32; you probably updated your
compiler and fell victim to this:

https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00104.html

I attached a patch.

--
``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-5.2.32/configure.ac Fri Sep 23 10:12:27 2022
--- configure.acTue Aug  6 09:19:00 2024
***
*** 886,890 
[AC_LANG_PROGRAM(
[[#include ]],
!   [[long double r; char *foo, bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
--- 886,890 
[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-5.2.32/configureWed Jul 31 09:44:19 2024
--- configure   Tue Aug  6 09:20:18 2024
***
*** 15677,15681 
  main (void)
  {
! long double r; char *foo, bar; r = strtold(foo, &bar);
  
;
--- 15677,15681 
  main (void)
  {
! long double r; char *foo, *bar; r = strtold(foo, &bar);
  
;

Re: Bogus (intptr_t) casts

[Martin D Kealey]

Why just those ones? Mainly:
(a) I'm looking at patching that area of the code for other reasons, so
they're the ones that I happened to encounter; and
(b) I didn't want to over-cook it, so I only included the ones where I
could see that it was actually a pointer (casting a number to an intptr_t
doesn't result in UB).

Other cases that involve casting a pointer to an intptr_t or uintptr_t, and
then comparing against a *numeric* zero should be similarly updated.

To my knowledge all current compilers use a numeric zero to represent
NULL,  but this is not guaranteed, and might change in the future.

-Martin


On Tue, 6 Aug 2024, 01:17 Chet Ramey,  wrote:

> On 8/1/24 4:12 AM, Martin D Kealey wrote:
>
>
> > It follows that the following assertions are allowed to fail:
> >
> >intptr_t i = 0;
> >assert(*(void*)i == (void*)0*);
> >void *p = 0;
> >assert(*(intptr_t)p == 0*);
> >
> > Accordingly I provide the following patch:
>
> I'm wondering why you chose these two cases, since there are other very
> similar uses of intptr_t casts.
>
> >
> > diff --git a/*subst.c* b/subst.c
> > index 37e0bfa7..140a3a92 100644
> > --- a/subst.c
> > +++ b/subst.c
> > @@ -6875,7 +6875,7 @@ uw_restore_pipeline (void *discard)
> >   static void
> >   uw_restore_errexit (void *eflag)
> >   {
> >
> > *-  change_flag ('e', (intptr_t) eflag ? FLAG_ON : FLAG_OFF);+
> change_flag
> > ('e', eflag ? FLAG_ON : FLAG_OFF);*
> > set_shellopts ();
> >   }
> >
> > diff --git a/*variables.c* b/variables.c
> > index cd336c85..d44453fe 100644
> > --- a/variables.c
> > +++ b/variables.c
> > @@ -5444,7 +5444,7 @@ pop_scope (void *is_special)
> > FREE (vcxt->name);
> > if (vcxt->table)
> >   {
> >
> > *-  if ((intptr_t) is_special)+  if (is_special)*
> >  hash_flush (vcxt->table, push_builtin_var);
> > else
> >  hash_flush (vcxt->table, push_exported_var);
>
> You might want to look at the unwind-protect implementation, which doesn't
> use assignments. It uses byte copies, so instead of using an assignment of,
> say, 0, where the compiler can assign whatever it wants to denote a NULL
> pointer, it copies 4-8 bytes, depending on the size of an integer. The cast
> of that memory back to an intptr_t should be transparent on all reasonably
> common systems.
>
> Of course, if you can provide an example where it fails, I'll look at it
> and fix 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: shell-expand-line working strangely without shebangs

[Chet Ramey]

> Thank you! Indeed a build from branch bash-5.3-testing shows the issue to be 
> fixed (devel did not build for me). I look forward to the release of the fix.

What error did you get when you tried to build devel? (I assume this was
on NixOS).

Chet

-- 
``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: waiting for process substitutions

[Zachary Santer]

On Tue, Aug 6, 2024 at 9:09 AM Oğuz  wrote:
>
> On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer  wrote:
> > I can not think of a time when I called 'wait' from the command line
> > that wasn't just for testing something. Even using process
> > substitutions on the command line is a relative rarity for me. If
> > we're balancing behavior on the command line against behavior in a
> > script, I think I'd give priority to scripting, at least here.
>
> This belongs on your personal blog.

How bash is actually used should guide its development. What are you
doing where you might want to call 'wait' from the interactive shell?

> > Chet doesn't see much value in making process substitutions jobs,
> > which I guess is fine. Can we agree that if they were made jobs,
> > though, waiting for all of them would be acceptable? You could see
> > them listed and handle them however you need.
>
> Making them jobs would be a bad idea. There are two major use cases of
> process substitutions:
> 1. Piping the output of a script to a command from within the script itself.

In a script, a child process being a job or not makes no difference,
from the shell programmer's perspective, unless you've got job control
on for some reason. The only difference it would make, as far as I can
tell, would be simplifying the implementation of 'wait', given that
there would be nothing besides jobs that it would be expected to wait
for. And with that implementation of 'wait', naturally, all procsubs
would be waited for by a call without id arguments.

> 2. Creating one-off FIFO files in scripts and on the command line.
> Neither use case would be improved if procsubs were made jobs. And
> it'd create too much noise for miniscule benefit.

Only as much noise as how many procsubs you expand on the command line.

Frankly, I was surprised that coprocs were jobs. But if there are
benefits to treating every asynchronous process besides elements of a
pipeline the same, within bash's implementation, I'm all for it.

Re: waiting for process substitutions

[Oğuz]

On Tuesday, August 6, 2024, Zachary Santer  wrote:
>
> How bash is actually used should guide its development.


Correct. No one waits for procsubs in their scripts or on the command line.

In a script, a child process being a job or not makes no difference,
> from the shell programmer's perspective, unless you've got job control
> on for some reason.


That's not true. `jobs' works even if job control is disabled. `kill'
accepts jobspecs and bash expands the `\j' escape sequence in prompt
strings. So it does make a difference.


> Only as much noise as how many procsubs you expand on the command line.
>

And that's too many. Much more than async jobs.


-- 
Oğuz

Potentially misleading documentation of SECONDS variable

[Bash-help via Bug reports for the GNU Bourne Again SHell]

Reading the manual at

regarding the SECONDS variable, it states that 
" [..] Assignment to this variable resets the count to the value assigned,
and the expanded value becomes the value assigned plus the number
of seconds since the assignment. [..]"

This implies that assigning the variable at time X with value Y would
reset SECONDS to Y. When expanding the variable at time X+Z the
value should be Y+Z. The text also implies whole seconds, i.e. not
milliseconds or other fractions of seconds, are considered. However, it would 
seem as if the
underlying mechanism to update SECONDS (the system clock)
are actually considering fractions of seconds and not whole seconds.
Below is a small programming that shows my point:

#!/bin/bash

while true; do
SECONDS=0
sleep 0.5
if [ "$SECONDS" != "0" ]; then
printf 'This is unexpected: %s != 0\n' "$SECONDS"
fi
done

As we sleep less than a full second the expanded value of SECONDS should never 
be greater than 0 but it sometimes is. I guess this is because the assignment 
might occur, say X.7 seconds and the expanded value will then read (X+1).2 
which would be rounded down to (X+1).

This might not be a bug but it is at least misleading when reading the 
documentation and produces unexpected and inconsistent behaviour in some cases.

Version of Bash used to test this behaviour:
GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu)

Re: Potentially misleading documentation of SECONDS variable

[alex xmb sw ratchev]

try

unset -v SECONDS

first

On Tue, Aug 6, 2024, 17:24 Bash-help via Bug reports for the GNU Bourne
Again SHell  wrote:

> Reading the manual at
> 
> regarding the SECONDS variable, it states that
> " [..] Assignment to this variable resets the count to the value assigned,
> and the expanded value becomes the value assigned plus the number
> of seconds since the assignment. [..]"
>
> This implies that assigning the variable at time X with value Y would
> reset SECONDS to Y. When expanding the variable at time X+Z the
> value should be Y+Z. The text also implies whole seconds, i.e. not
> milliseconds or other fractions of seconds, are considered. However, it
> would seem as if the
> underlying mechanism to update SECONDS (the system clock)
> are actually considering fractions of seconds and not whole seconds.
> Below is a small programming that shows my point:
>
> #!/bin/bash
>
> while true; do
> SECONDS=0
> sleep 0.5
> if [ "$SECONDS" != "0" ]; then
> printf 'This is unexpected: %s != 0\n' "$SECONDS"
> fi
> done
>
> As we sleep less than a full second the expanded value of SECONDS should
> never be greater than 0 but it sometimes is. I guess this is because the
> assignment might occur, say X.7 seconds and the expanded value will then
> read (X+1).2 which would be rounded down to (X+1).
>
> This might not be a bug but it is at least misleading when reading the
> documentation and produces unexpected and inconsistent behaviour in some
> cases.
>
> Version of Bash used to test this behaviour:
> GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu)
>

Re: Potentially misleading documentation of SECONDS variable

[Koichi Murase]

2024年8月7日(水) 0:24 Bash-help via Bug reports for the GNU Bourne Again
SHell :
> Reading the manual at
> 
> regarding the SECONDS variable, it states that
> " [..] Assignment to this variable resets the count to the value assigned,
> and the expanded value becomes the value assigned plus the number
> of seconds since the assignment. [..]"
>
> [...]
>
> As we sleep less than a full second the expanded value of SECONDS should 
> never be greater than 0 but it sometimes is. I guess this is because the 
> assignment might occur, say X.7 seconds and the expanded value will then read 
> (X+1).2 which would be rounded down to (X+1).

I think the next sentence in the manual

https://www.gnu.org/software/bash/manual/bash.html#Bash-Variables
> [...] The number of seconds at shell
> invocation and the current time are always determined by querying the
> system clock. [...]

is supposed to imply that technically. It says "The number of seconds
at shell invocation", so the starting time point is considered to have
only the "second" resolution and doesn't have the subsecond
resolution. Then, when a value is assigned, the starting time point
would be updated to the number of "seconds" at the assignment.

For example, when the assignment occurs at time X.7, the recorded time
becomes just X (with the fraction part being truncated). Then, the
value obtained from SECONDS is incremented when the clock becomes
(X+1).0. This is consistent with the observed behavior.

However, I agree that this is implicit and ambiguous. A minimal
modification is probably something like

diff --git a/doc/bash.1 b/doc/bash.1
index 1f0a23d3..3ace21e9 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -2091,7 +2091,7 @@ the value returned upon subsequent
 references is
 the number of seconds since the assignment plus the value assigned.
 The number of seconds at shell invocation and the current time are always
-determined by querying the system clock.
+determined by querying the system clock at the resolution of a second.
 If
 .SM
 .B SECONDS
diff --git a/doc/bashref.texi b/doc/bashref.texi
index 510b43f6..6ee0083b 100644
--- a/doc/bashref.texi
+++ b/doc/bashref.texi
@@ -7038,7 +7038,7 @@ Assignment to this variable resets the count to
the value assigned, and the
 expanded value becomes the value assigned plus the number of seconds
 since the assignment.
 The number of seconds at shell invocation and the current time are always
-determined by querying the system clock.
+determined by querying the system clock at the resolution of a second.
 If @env{SECONDS}
 is unset, it loses its special properties,
 even if it is subsequently reset.

--
Koichi

Re: Potentially misleading documentation of SECONDS variable

[alex xmb sw ratchev]

i think this includes
if u start a bash
set clock 1h to future
and query after 1s , it may show not 0 or 1 second

On Tue, Aug 6, 2024, 18:26 Koichi Murase  wrote:

> 2024年8月7日(水) 0:24 Bash-help via Bug reports for the GNU Bourne Again
> SHell :
> > Reading the manual at
> > 
> > regarding the SECONDS variable, it states that
> > " [..] Assignment to this variable resets the count to the value
> assigned,
> > and the expanded value becomes the value assigned plus the number
> > of seconds since the assignment. [..]"
> >
> > [...]
> >
> > As we sleep less than a full second the expanded value of SECONDS should
> never be greater than 0 but it sometimes is. I guess this is because the
> assignment might occur, say X.7 seconds and the expanded value will then
> read (X+1).2 which would be rounded down to (X+1).
>
> I think the next sentence in the manual
>
> https://www.gnu.org/software/bash/manual/bash.html#Bash-Variables
> > [...] The number of seconds at shell
> > invocation and the current time are always determined by querying the
> > system clock. [...]
>
> is supposed to imply that technically. It says "The number of seconds
> at shell invocation", so the starting time point is considered to have
> only the "second" resolution and doesn't have the subsecond
> resolution. Then, when a value is assigned, the starting time point
> would be updated to the number of "seconds" at the assignment.
>
> For example, when the assignment occurs at time X.7, the recorded time
> becomes just X (with the fraction part being truncated). Then, the
> value obtained from SECONDS is incremented when the clock becomes
> (X+1).0. This is consistent with the observed behavior.
>
> However, I agree that this is implicit and ambiguous. A minimal
> modification is probably something like
>
> diff --git a/doc/bash.1 b/doc/bash.1
> index 1f0a23d3..3ace21e9 100644
> --- a/doc/bash.1
> +++ b/doc/bash.1
> @@ -2091,7 +2091,7 @@ the value returned upon subsequent
>  references is
>  the number of seconds since the assignment plus the value assigned.
>  The number of seconds at shell invocation and the current time are always
> -determined by querying the system clock.
> +determined by querying the system clock at the resolution of a second.
>  If
>  .SM
>  .B SECONDS
> diff --git a/doc/bashref.texi b/doc/bashref.texi
> index 510b43f6..6ee0083b 100644
> --- a/doc/bashref.texi
> +++ b/doc/bashref.texi
> @@ -7038,7 +7038,7 @@ Assignment to this variable resets the count to
> the value assigned, and the
>  expanded value becomes the value assigned plus the number of seconds
>  since the assignment.
>  The number of seconds at shell invocation and the current time are always
> -determined by querying the system clock.
> +determined by querying the system clock at the resolution of a second.
>  If @env{SECONDS}
>  is unset, it loses its special properties,
>  even if it is subsequently reset.
>
> --
> Koichi
>
>

Re: Potentially misleading documentation of SECONDS variable

[bash]

On Wed, Aug 07, 2024 at 01:25:35AM +0900, Koichi Murase wrote:
> is supposed to imply that technically. It says "The number of seconds
> at shell invocation", so the starting time point is considered to have
> only the "second" resolution and doesn't have the subsecond
> resolution. Then, when a value is assigned, the starting time point
> would be updated to the number of "seconds" at the assignment.
> 
"seconds" being in quotes here since it is not actually the "number of
seconds" but rather "the time passed truncated to whole-second
resolution". :) 

> For example, when the assignment occurs at time X.7, the recorded time
> becomes just X (with the fraction part being truncated). Then, the
> value obtained from SECONDS is incremented when the clock becomes
> (X+1).0. This is consistent with the observed behavior.
> 
I agree! It's the truncating part that is the cause of this
confusion.

> However, I agree that this is implicit and ambiguous. A minimal
> modification is probably something like
> 
> diff --git a/doc/bash.1 b/doc/bash.1
> index 1f0a23d3..3ace21e9 100644
> --- a/doc/bash.1
> +++ b/doc/bash.1
> @@ -2091,7 +2091,7 @@ the value returned upon subsequent
>  references is
>  the number of seconds since the assignment plus the value assigned.
>  The number of seconds at shell invocation and the current time are always
> -determined by querying the system clock.
> +determined by querying the system clock at the resolution of a second.
>  If
>  .SM
>  .B SECONDS
> diff --git a/doc/bashref.texi b/doc/bashref.texi
> index 510b43f6..6ee0083b 100644
> --- a/doc/bashref.texi
> +++ b/doc/bashref.texi
> @@ -7038,7 +7038,7 @@ Assignment to this variable resets the count to
> the value assigned, and the
>  expanded value becomes the value assigned plus the number of seconds
>  since the assignment.
>  The number of seconds at shell invocation and the current time are always
> -determined by querying the system clock.
> +determined by querying the system clock at the resolution of a second.
>  If @env{SECONDS}
>  is unset, it loses its special properties,
>  even if it is subsequently reset.
>
Ideally, I would have it stating something about the possible
discrepancy due to truncating the underlaying, higher resolution value.
Maybe something like:
" +determined by querying the system clock, disregarding any subsecond
portion of the system clock value"
Such information would have helped me understand what is happening, at
least :)

Re: Bogus (intptr_t) casts

[Chet Ramey]

On 8/6/24 9:36 AM, Martin D Kealey wrote:

Why just those ones? Mainly:
(a) I'm looking at patching that area of the code for other reasons, so 
they're the ones that I happened to encounter; and
(b) I didn't want to over-cook it, so I only included the ones where I 
could see that it was actually a pointer (casting a number to an intptr_t 
doesn't result in UB).


Other cases that involve casting a pointer to an intptr_t or uintptr_t, and 
then comparing against a *numeric* zero should be similarly updated.


You didn't address the other part of my message. Since the pointers that
are in unwind-protects are the result of byte copies, not assignments, the
compiler's representation of NULL pointers isn't relevant.

To my knowledge all current compilers use a numeric zero to represent 
NULL,  but this is not guaranteed, and might change in the future.


It doesn't matter. The four (or eight) bytes in the (void *) that is cast
to an intptr_t are the result of copying the original four (or eight) bytes
in the int that's being saved.

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

whats wrong , exit code 11 on android termux

[alex xmb sw ratchev]

~ $ alias tm='timemark+=( $EPOCHREALTIME )'
~ $ tm

[Process completed (signal 11) - press Enter]

btw is it to send to bug and help .. ?

Re: waiting for process substitutions

[Zachary Santer]

On Tue, Aug 6, 2024 at 10:21 AM Oğuz  wrote:
>
> On Tuesday, August 6, 2024, Zachary Santer  wrote:
>>
>> How bash is actually used should guide its development.
>
> Correct. No one waits for procsubs in their scripts or on the command line.

On Wed, Jul 3, 2024 at 8:40 PM Zachary Santer  wrote:
>
> In my actual use cases, I have:
>
> (1)
> A couple different scripts that alternate reading from multiple
> different processes, not entirely unlike
> sort -- <( command-1 ) <( command-2 ) <( command-3 )
> except it's using exec and automatic fds.
>
> ( 2 )
> shopt -s lastpipe
> exec {fd}> >( command-2 )
> command-1 |
>   while [...]; do
> [...]
> if [[ ${something} == 'true' ]]; then
>   printf '%s\x00' "${var}" >&"${fd}"
> fi
>   done
> #
> exec {fd}>&-
>
> This whole arrangement is necessary because I need what's going on in
> the while loop to be in the parent shell if I'm going to use coproc
> fds directly. What's going on in the process substitution will more or
> less only begin when the fd it's reading from is closed, because it
> involves at least one call to xargs.

"No one." It is necessary in both of the above use-cases to wait for
the procsub(s) to terminate. In (1), the script can close the reading
end of the pipe to one of the procsubs before all the output from the
command within has been read. It would be best to ensure that all
procsub child processes have terminated before the script exits. In
(2), the procsub child process really only does its work once the
writing end of the pipe has been closed. Again, It is necessary to
wait for that child process to terminate before the script exits.

Because the versions of these scripts that actually get used run in
bash-4.2, which was incapable of waiting for procsubs, other solutions
had to be found: FIFOs in the case of (1) and making what would've
been in a procsub in (2) the final element of a pipeline. Managing the
FIFOs in (1) adds roughly 29 lines, collectively, to my scripts that
work this way, compared to the bash-4.4 versions that use procsubs. No
clue how much creating a temporary directory and the pipes to put in
it adds to the run time. Without procsubs or a FIFO, there's no way to
get the middle element of the pipeline in (2) into the parent shell
environment. Just a matter of luck that it didn't need to be there.

This I guess makes a further point about the need to anticipate what
shell programmers might want or need to be able to do. Which is what
I'm trying to help with here.

>> In a script, a child process being a job or not makes no difference,
>> from the shell programmer's perspective, unless you've got job control
>> on for some reason.
>
>
> That's not true. `jobs' works even if job control is disabled. `kill' accepts 
> jobspecs and bash expands the `\j' escape sequence in prompt strings. So it 
> does make a difference.

Things I have no experience with. Fine.

>> Only as much noise as how many procsubs you expand on the command line.
>
>
> And that's too many. Much more than async jobs.

Async jobs like graphical applications you've launched from the shell,
shall-based text editors, 'man', 'info', etc., maybe a build you're
running in the background. You use procsubs in the interactive shell
more than this type of stuff?

Re: whats wrong , exit code 11 on android termux

[Grisha Levit]

On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev  wrote:

> ~ $ alias tm='timemark+=( $EPOCHREALTIME )'
> ~ $ tm
>
> [Process completed (signal 11) - press Enter]
>

I believe this was reported in
https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00146.html and fixed
in https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=a629483b0

>

Re: whats wrong , exit code 11 on android termux

[alex xmb sw ratchev]

maybe its this i completly dunno

i guess i must start use devel branch ?

On Tue, Aug 6, 2024, 20:45 Grisha Levit  wrote:

> On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev  wrote:
>
>> ~ $ alias tm='timemark+=( $EPOCHREALTIME )'
>> ~ $ tm
>>
>> [Process completed (signal 11) - press Enter]
>>
>
> I believe this was reported in
> https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00146.html and
> fixed in
> https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=a629483b0
>
>>

Re: whats wrong , exit code 11 on android termux

[Greg Wooledge]

On Tue, Aug 06, 2024 at 20:59:08 +0200, alex xmb sw ratchev wrote:
> maybe its this i completly dunno
> 
> i guess i must start use devel branch ?
> 
> On Tue, Aug 6, 2024, 20:45 Grisha Levit  wrote:
> 
> > On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev  wrote:
> >
> >> ~ $ alias tm='timemark+=( $EPOCHREALTIME )'
> >> ~ $ tm
> >>
> >> [Process completed (signal 11) - press Enter]

As a temporary workaround, you could write a function instead of an alias.

Re: waiting for process substitutions

[Oğuz]

On Tuesday, August 6, 2024, Zachary Santer  wrote:
>
> This I guess makes a further point about the need to anticipate what
> shell programmers might want or need to be able to do.


To me it just shows how lost you are, sorry. Perhaps you should consider
other languages, or write a utility that makes setting up FIFOs easier, I
don't know.


-- 
Oğuz

Re: whats wrong , exit code 11 on android termux

[alex xmb sw ratchev]

my argument against function was its way slower
it isnt much for this project but the overall ' timings adding ' project

if its a bash bug , my code's not fault , and i really prefer such be fixed

On Tue, Aug 6, 2024, 21:07 Greg Wooledge  wrote:

> On Tue, Aug 06, 2024 at 20:59:08 +0200, alex xmb sw ratchev wrote:
> > maybe its this i completly dunno
> >
> > i guess i must start use devel branch ?
> >
> > On Tue, Aug 6, 2024, 20:45 Grisha Levit  wrote:
> >
> > > On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev 
> wrote:
> > >
> > >> ~ $ alias tm='timemark+=( $EPOCHREALTIME )'
> > >> ~ $ tm
> > >>
> > >> [Process completed (signal 11) - press Enter]
>
> As a temporary workaround, you could write a function instead of an alias.
>
>

Re: whats wrong , exit code 11 on android termux

[alex xmb sw ratchev]

.. thanks tho , greycat ..
greets ..

On Tue, Aug 6, 2024, 21:38 alex xmb sw ratchev  wrote:

> my argument against function was its way slower
> it isnt much for this project but the overall ' timings adding ' project
>
> if its a bash bug , my code's not fault , and i really prefer such be fixed
>
> On Tue, Aug 6, 2024, 21:07 Greg Wooledge  wrote:
>
>> On Tue, Aug 06, 2024 at 20:59:08 +0200, alex xmb sw ratchev wrote:
>> > maybe its this i completly dunno
>> >
>> > i guess i must start use devel branch ?
>> >
>> > On Tue, Aug 6, 2024, 20:45 Grisha Levit  wrote:
>> >
>> > > On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev 
>> wrote:
>> > >
>> > >> ~ $ alias tm='timemark+=( $EPOCHREALTIME )'
>> > >> ~ $ tm
>> > >>
>> > >> [Process completed (signal 11) - press Enter]
>>
>> As a temporary workaround, you could write a function instead of an alias.
>>
>>

Re: Potentially misleading documentation of SECONDS variable

[Chet Ramey]

On 8/6/24 11:17 AM, Bash-help via Bug reports for the GNU Bourne Again 
SHell wrote:

Reading the manual at

regarding the SECONDS variable, it states that
" [..] Assignment to this variable resets the count to the value assigned,
and the expanded value becomes the value assigned plus the number
of seconds since the assignment. [..]"

This implies that assigning the variable at time X with value Y would
reset SECONDS to Y. When expanding the variable at time X+Z the
value should be Y+Z. The text also implies whole seconds, i.e. not
milliseconds or other fractions of seconds, are considered. However, it would 
seem as if the
underlying mechanism to update SECONDS (the system clock)
are actually considering fractions of seconds and not whole seconds.


The system clock (at least on all of the systems worth considering at this
point) has always kept fractions of a second. Bash has never looked at
anything but whole seconds. From when I first added SECONDS in 1989 through
bash-5.1, it used time(3). In bash-5.1, I changed it to use the tv_sec 
member of the struct from gettimeofday (which is essentially what modern

versions of time(3) do), but it's never rounded up or attempted to perform
tv_usec or tv_nsec arithmetic.

If you're interested in that kind of sub-second precision, use
EPOCHREALTIME. If you want something that's not affected by assignment,
use EPOCHSECONDS.

--
``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: Potentially misleading documentation of SECONDS variable

[bash]

On Tue, Aug 06, 2024 at 03:58:35PM -0400, Chet Ramey wrote:
> [...] Bash has never looked at
> anything but whole seconds. [...]
> 
Ok, cool. So this is not a bug but rather just how Bash works. That's
fine but then I think the documentation could reflect the actual
behaviour better. I found this "edge case" (where it seemed as if Bash
sometimes failed at calculating the correct value) a bit confusing.
Maybe I was using Bash in a "non-standard" way, not as it was supposed
to... But still, I think the behaviour could be more intuitive. From
reading the manual I expected a different behaviour but since I have
not coded anything on Bash myself I know I have no right to anything
else than an opinion :)

> If you're interested in that kind of sub-second precision, use
> EPOCHREALTIME. If you want something that's not affected by assignment,
> use EPOCHSECONDS.
> 
I am not. I have since this "discovery" learnt to use lower case
variable names which solves all and every issue I had before. Opening
this issue was merely an attempt to raise the question on if and how
Bash could be improved.

Re: Potentially misleading documentation of SECONDS variable

[Ángel]

On 2024-08-06 at 17:17 +0200, Bash-help via Bug reports for the GNU
Bourne Again SHell wrote:
> #!/bin/bash
> 
> while true; do
> SECONDS=0
> sleep 0.5
> if [ "$SECONDS" != "0" ]; then
> printf 'This is unexpected: %s != 0\n' "$SECONDS"
> fi
> done
> 
> As we sleep less than a full second the expanded value of SECONDS
> should never be greater than 0 but it sometimes is. I guess this is
> because the assignment might occur, say X.7 seconds and the expanded
> value will then read (X+1).2 which would be rounded down to (X+1).

Please note that the contract with the OS is to sleep *at least* half a
second. You have no guarantee that it won't sleep more. Typically,
after half a second the process will return to the list of programs
ready to be executed, and get a time slot depending on the number of
processes ready, the system load, etc.

In POSIX description of sleep(2):

> The suspension time may be longer than requested due to the
scheduling of other activity by the system.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/sleep.html


For big values such as 0.5, that delay is unlikely to be relevant, but
one should not assume the sleep will be exactly the specified amount
and no more.

Regards

Re: waiting for process substitutions

[Zachary Santer]

On Tue, Aug 6, 2024 at 3:20 PM Oğuz  wrote:
>
> To me it just shows how lost you are, sorry. Perhaps you should consider 
> other languages, or write a utility that makes setting up FIFOs easier, I 
> don't know.

All the scripts I've discussed in this email list run and act on the
output of external commands. Using a different language would simply
result in still calling those same external commands, but in a less
natural way, and I don't know of anything else that can do the
following particularly well:

command |
  while IFS='' read -r line; do
# do stuff
  done
#

I don't want to have to write my own implementation of 'git diff' in
Python or whatever, when there's already a perfectly good program that
a lot of people have put a lot of time into.

Yes, accomplishing some things in bash has required creative thinking,
but I think I've mostly come up with reasonable solutions.

You can benefit from my experience or not.