Dunno if it's "considerably easier", my patch just added 1 sign argument to
1 function and fixed up a couple of call sites.
Your way is shorter but it boils down to "if the micro-part is negative it
means that the number was in (-1,0)", which for some reason was already
being checked for despite no
On 10/19/22 5:22 PM, Andrew Neff via Bug reports for the GNU Bourne Again
SHell wrote:
Bash Version: 5.1
Patch Level: 12
Release Status: release
Description:
I discovered an inconsistent bug starting in bash 5.1.12. Setting the
EXIT trap in the grandparent of a subshell that exits vi
On 10/18/22 1:47 PM, Andrew Neff via Bug reports for the GNU Bourne Again
SHell wrote:
Description:
Using the "caller" command on a line of bash code in a process substitution
has been incorrect from bash 3.2 through 5.1, but I could write my code in such a way to
work around it. Some of t
On 10/22/22 2:58 PM, izabera wrote:
if the argument is in the (-1, 0) range, the integer part is zero and
multiplying it by -1 has no effect, so the caller can't tell that the
argument was negative
I suggest that a considerably easier way to solve this is
*** ../bash-5.2-patched/lib/sh/uconver
Date:Mon, 24 Oct 2022 16:16:21 +0200
From:Emanuele Torre
Message-ID:
| It does not make any sense that you keep insisting that this is about
| bash internals, or low level system call (especially `wait', `fork',
| etc),
Since that is the exact opposite of wha
On 24/10/2022, Robert Elz wrote:
> | The problem that was described is caused by that
> | optimisation (not the version that is applied to simple commands that
> | run external program, but to subshell compound command as mentioned).
>
> I understand that.
>
> | In case you did not underst
Date:Mon, 24 Oct 2022 10:52:22 +0200
From:Emanuele Torre
Message-ID:
| I don't see how this is relevant.
See below.
| Process substitutions are considered background jobs, and the wait
| builtin waits for them.
That's fine.
| > That is an entirely differ
On 24/10/2022, Robert Elz wrote:
> It need not make a difference. The wait command is not intended to
> be just the wait(2) (or wait(3) whichever it is on the system in
> question) system call (or wrapper around another system call).
I don't see how this is relevant.
> There's no reason that w
24 Ekim 2022 Pazartesi tarihinde Robert Elz yazdı:
> [...] That the shell happens to
> have forked other processes for its own reasons should make no
> difference at all.
Agreed.
In the case of process substitutions it is documented that their use may
change wait's behavior
> If id is not
> g