On 09/27/11 22:44, Sandro Santilli wrote:
> A warning/error message with hint on how to correctly form
> the string would be very friendly for users
Unfortunately, there's no portable way to determine
which TZ values are supported on the current platform.
One cannot even reliably determine whether
On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> Pádraig Brady writes:
>
> > $ TZ=GB-Eire+1 date
>
> A POSIX timezone name cannot have dashes.
Doesn't all these "can't have" and "undefined" specs mean
we do can warn or error out w/out breakin POSIX compatibility ?
> > $ TZ=Jap
On Tue, Sep 27, 2011 at 11:52:22PM +0200, Andreas Schwab wrote:
> Pádraig Brady writes:
>
> > On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> >> I've been puzzled by date(1) giving weird results
> >> when setting TZ to values unknown by zoneinfo.
> >>
> >> As far as:
> >>
> >> $ TZ=Fake date
Pádraig Brady writes:
> $ TZ=GB-Eire+1 date
A POSIX timezone name cannot have dashes.
> $ TZ=Japan+1 date
This is a well-formed POSIX timezone.
> $ TZ=Japan date
This is a non-POSIX timezone that happens to match an Olson timezone.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On 09/27/2011 10:47 PM, Andreas Schwab wrote:
> Pádraig Brady writes:
>
>> $ TZ=NZ+1 date # No zone reported
>
> This is undefined. A zone name in a POSIX time zone must have at least
> three letters.
I considered that, but it seems inconsequential in this case.
I'd advise people to stay clea
Pádraig Brady writes:
> $ TZ=NZ+1 date # No zone reported
This is undefined. A zone name in a POSIX time zone must have at least
three letters.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something c
Pádraig Brady writes:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>>
>> As far as:
>>
>> $ TZ=Fake date
>> Tue Sep 27 14:06:32 Fake 2011
>
> Yes, that is per POSIX.
This is not a POSIX
Paul Eggert writes:
> On 09/27/11 13:07, Andreas Schwab wrote:
>> Padding bits can change any time.
>
> Is there any way to compare the non-padding parts of long doubles?
By ignoring the padding.
> There ought to be *some* way to get the fractional part of a NaN, no?
You need to inspect the by
=?UTF-8?Q?P=C3=A1draig?= Brady writes:
>
> BTW that ^C being displayed (started around Fedora 11 time (2.6.30))
> is very annoying, especially when inserted in the middle of an ANSI code.
> I mentioned that previously here:
> http://mail.linux.ie/pipermail/ilug/2011-February/106723.html
I've been
On 09/27/2011 08:33 PM, Paul Eggert wrote:
> This happened with coreutils 8.13 on Fedora 14 x86-64
> (coreutils compiled with GCC 4.6.1). I interrupted
> 'dd' with control-C, but it didn't respond right away;
> instead, it churned away and created the entire output file,
> issuing a bogus diagnost
On 09/27/2011 07:19 PM, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>>
>> As far as:
>>
>> $ TZ=Fake date
>> Tue Sep 27 14:06:32 Fake 2011
>
> Yes, that is per POSIX.
> Is there any way to compare the non-padding parts of long doubles?
> There ought to be *some* way to get the fractional part of a NaN, no?
frexp() [man 3 frexp] would be the right idea,
except that it fails explicitly for NaN.
--
On 09/27/2011 12:33 PM, Paul Eggert wrote:
> This happened with coreutils 8.13 on Fedora 14 x86-64
> (coreutils compiled with GCC 4.6.1). I interrupted
> 'dd' with control-C, but it didn't respond right away;
> instead, it churned away and created the entire output file,
> issuing a bogus diagnost
Paul Eggert wrote:
> On 09/27/11 13:07, Andreas Schwab wrote:
>> Padding bits can change any time.
>
> Is there any way to compare the non-padding parts of long doubles?
> There ought to be *some* way to get the fractional part of a NaN, no?
> For example, with glibc, is there some way to sprintf t
On 09/27/11 13:07, Andreas Schwab wrote:
> Padding bits can change any time.
Is there any way to compare the non-padding parts of long doubles?
There ought to be *some* way to get the fractional part of a NaN, no?
For example, with glibc, is there some way to sprintf to a buffer
and get the fracti
Jim Meyering writes:
> However, I am dismayed that with glibc's strtold the values of those bits
> is not deterministic.
Padding bits can change any time.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for so
On Tue, Sep 27, 2011 at 07:19:12PM +0100, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> > I've been puzzled by date(1) giving weird results
> > when setting TZ to values unknown by zoneinfo.
> >
> > As far as:
> >
> > $ TZ=Fake date
> > Tue Sep 27 14:06:32 Fake 2011
>
This happened with coreutils 8.13 on Fedora 14 x86-64
(coreutils compiled with GCC 4.6.1). I interrupted
'dd' with control-C, but it didn't respond right away;
instead, it churned away and created the entire output file,
issuing a bogus diagnostic about the input file. Here's
the transcript:
$ d
On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> I've been puzzled by date(1) giving weird results
> when setting TZ to values unknown by zoneinfo.
>
> As far as:
>
> $ TZ=Fake date
> Tue Sep 27 14:06:32 Fake 2011
Yes, that is per POSIX.
One can specify info about the timezone in TZ
like TZ="F
Andreas Schwab wrote:
> Jim Meyering writes:
>
>> The statement "long double x = NAN;" (inside glibc's strtold) leaves many
>> bits of "x" uninitialized.
>
> You are looking at padding bits, which have unspecified contents.
I realize that they are unspecified.
That is why I did not claim that thi
I've been puzzled by date(1) giving weird results
when setting TZ to values unknown by zoneinfo.
As far as:
$ TZ=Fake date
Tue Sep 27 14:06:32 Fake 2011
It would be more helpful if the command raised an error
or warning about "unknown" timezones rather than giving
random dates.
It's particul
Jim Meyering writes:
> The statement "long double x = NAN;" (inside glibc's strtold) leaves many
> bits of "x" uninitialized.
You are looking at padding bits, which have unspecified contents.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D
This was reported by Aaron Denney in http://bugs.debian.org/642557.
Who would have thought that including a few NaNs in the input to sort
would make it infloop.
The original failure arose only when sort was reading from a pipe:
yes -- -nan | head -156903 | sort -g > /dev/null
But it's not a
Jim,
Any news about this bug?
This problem was again reported against a recent Debian release here:
http://article.gmane.org/gmane.comp.file-systems.fuse.sshfs/1200
Thanks,
Miklos
tags 9611 notabug
On 09/27/2011 02:23 PM, Peng Yu wrote:
> Hi,
>
> Suppose I have a file 'a/b/c/d/e/f', I want to copy it to 'target'
> with the parent 'd/e'. I.e., the resulted file is 'target/d/e/f'.
>
> I can make a bash script to do so, but I wondering if there is an
> existing command or op
Hi,
Suppose I have a file 'a/b/c/d/e/f', I want to copy it to 'target'
with the parent 'd/e'. I.e., the resulted file is 'target/d/e/f'.
I can make a bash script to do so, but I wondering if there is an
existing command or option. Thanks!
--
Regards,
Peng
26 matches
Mail list logo
