On 8/22/21 7:52 PM, Kerin Millar wrote:
On Sun, 22 Aug 2021 16:13:28 -0400
Chet Ramey wrote:
On 8/21/21 1:28 AM, Emanuele Torre wrote:
Bash Version: 5.1
Patch Level: 8
Release Status: release
get_epochrealtime() casts tv.tv_sec (a time_t a.k.a. int) to unsigned
int causing EPOCHREALTIME
On Sun, 22 Aug 2021 16:13:28 -0400
Chet Ramey wrote:
> On 8/21/21 1:28 AM, Emanuele Torre wrote:
>
> > Bash Version: 5.1
> > Patch Level: 8
> > Release Status: release
> >
>
> > get_epochrealtime() casts tv.tv_sec (a time_t a.k.a. int) to unsigned
> > int causing EPOCHREALTIME to not behave co
lol undefined behavior, tho its important to test such important
functionality, as setting time back
bad book by the live of 'use your computer only so'
im just saying nowadays as earlier software is more ugly bugs than useful
On Sun, Aug 22, 2021, 23:28 Greg Wooledge wrote:
> On Sun, Aug 22,
On Sun, Aug 22, 2021 at 10:30:26PM +0200, Alex fxmbsw7 Ratchev wrote:
> why disregard or invalid, mark 0 is that date, less is minus, .. all working
It's not that simple. Calendars get really *interesting* if you go
farther back in history. The switch from the Julian to the Gregorian
calendar di
why disregard or invalid, mark 0 is that date, less is minus, .. all working
On Sun, Aug 22, 2021, 22:13 Chet Ramey wrote:
> On 8/21/21 1:28 AM, Emanuele Torre wrote:
>
> > Bash Version: 5.1
> > Patch Level: 8
> > Release Status: release
> >
>
> > get_epochrealtime() casts tv.tv_sec (a time_t a.
On 8/21/21 1:28 AM, Emanuele Torre wrote:
Bash Version: 5.1
Patch Level: 8
Release Status: release
get_epochrealtime() casts tv.tv_sec (a time_t a.k.a. int) to unsigned
int causing EPOCHREALTIME to not behave correctly before the Unix Epoch.
The definition is seconds since the Unix epoch.
Date:Sat, 21 Aug 2021 07:28:23 +0200
From:Emanuele Torre
Message-ID:
| I have also read that gettimeofday() is considered obsolete and is
| deprecated by POSIX.
It is being removed as a required interface, but it still exists
everywhere (and will for a very lon
On 8/19/21 12:18 PM, Léa Gris wrote:
> Le 19/08/2021 à 16:41, Eli Schwartz écrivait :
>> On 8/19/21 9:41 AM, Léa Gris wrote:
>
>
>> The error occurs, one would imagine, during the "convert string to
>> float" stage, after parsing argv or forking to bc or whatever, but
>> *before* passing it as an
On Thu, Aug 19, 2021 at 06:18:46PM +0200, Léa Gris wrote:
> printf arguments are program source even if argument comes from a variable.
I don't agree with this. I'd say that the *first* argument of printf
is part of the program source code, and any additional arguments given
are typically data, b
Le 19/08/2021 à 16:41, Eli Schwartz écrivait :
On 8/19/21 9:41 AM, Léa Gris wrote:
The error occurs, one would imagine, during the "convert string to
float" stage, after parsing argv or forking to bc or whatever, but
*before* passing it as an argument to printf(3). Here, bash is just
doing go
On Thu, Aug 19, 2021 at 10:30:39AM -0400, Chet Ramey wrote:
> On 8/19/21 9:41 AM, Léa Gris wrote:
> > This will fail because of questionable design decision of having a mutable
> > argument format:
> >
> > LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')"
> >
> > Note how the fo
On 8/19/21 9:41 AM, Léa Gris wrote:
> Le 19/08/2021 à 15:10, hancooper écrivait :
>> Thusly, EPOCHREALTIME should not be made to depend on the locale. I
>> have seen many
>> workarounds, that complicate rather than simplify something that
>> should be straighforward
>> and germaine to direct numer
On 8/19/21 9:41 AM, Léa Gris wrote:
> This will fail because of questionable design decision of having a mutable
> argument format:
>
> LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')"
>
> Note how the format indicator still use a dot, but the argument format's
> decimal separ
Le 19/08/2021 à 15:10, hancooper écrivait :
Thusly, EPOCHREALTIME should not be made to depend on the locale. I have seen
many
workarounds, that complicate rather than simplify something that should be
straighforward
and germaine to direct numeric computation.
A agree 100%
It is as frustrat
On Thu, Aug 19, 2021 at 4:12 PM hancooper wrote:
> On Thursday, August 19, 2021 12:58 PM, Léa Gris
> wrote:
> > (LC_NUMERIC=C; echo "$EPOCHREALTIME")
>
> the unix time stamp is merely the number of
> seconds between a particular date and the epoch. Technically, it should
> be pointed out
> that
Le 19/08/2021 à 14:43, hancooper via Bug reports for the GNU Bourne
Again SHell écrivait :
Have been using $EPOCHREALTIME but can see that the output is as follows.
1629376497,853634
The utilisation of tho comma `,` is very inconvenient for those who want to do
time
computations. A change towa
16 matches
Mail list logo
