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
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
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
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 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
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
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
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
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 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
>
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 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
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/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
> 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 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.
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
=?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
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
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
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
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=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 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
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 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
26 matches
Mail list logo
