Pádraig Brady <[EMAIL PROTECTED]> writes:
> Thank you for the explanation and fixing this up.
You're welcome. And thanks for supplying such a fun problem,
(though perhaps I should qualify that by saying it was more fun than
what I should have been working on, which was grading my students'
work.
Micah Cowan <[EMAIL PROTECTED]> writes:
> f making seq act as if it were counting in decimal for fractions,
> instead of binary floating-point, is really something we want to
> consider, then why don't we actually have seq represent fractions in
> decimal, internally?
Yes, that would be better.
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> I haven't time to look at this now,
>> but will soon.
>
> Thanks.
>
>> A couple of points came to mind.
>>
>> Is it OK to look at just 1 value "after" last?
>
> It should not be necessary to look 2 values "after" last. The pro
Thanks for replying. I should've known it was not a bug but a coding
error on my part. I apologize for crying wolf!
Brian Dessent <[EMAIL PROTECTED]>
06/22/2007 01:10 PM
Please respond to bug-coreutils
To: [EMAIL PROTECTED]
cc: bug-coreutils@gnu.org
bcc:
f making seq act as if it were counting in decimal for fractions,
instead of binary floating-point, is really something we want to
consider, then why don't we actually have seq represent fractions in
decimal, internally? Isn't that the only real way we could possibly
expect seq to "do what the user
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
...
>> Aren't you susceptible to whatever rounding
>> printf does internally?
>
> Yes, that's quite true. One can easily construct examples where the
> revised "seq" is mathematically incorrect, due to this problem.
Pádraig Brady <[EMAIL PROTECTED]> writes:
> I haven't time to look at this now,
> but will soon.
Thanks.
> A couple of points came to mind.
>
> Is it OK to look at just 1 value "after" last?
It should not be necessary to look 2 values "after" last. The problem
we're trying to address is the bu
[EMAIL PROTECTED] wrote:
>I would like to report what I think is a bug: why the following linux
> "date" command fails to run within a shell script. But, in runs fine on
> the command line. I'm running 2.6.21-1.3194.fc7 on a IBM Thinkpad. I've
> also tested on an IBM eServer running 2.6.9-55.E
Hi there,
You simply need to use quotes, much like you did on the command line. Thus
EDATE=`date +'%s' -d $TDATE`
becomes
EDATE=`date +'%s' -d "$TDATE"`
... and so on for your other references to $TDATE.
Regards,
Mark
On Friday 22 June 2007 9:07:22 am [EMAIL PROTECTED] wrote:
>I would li
I would like to report what I think is a bug: why the following linux
"date" command fails to run within a shell script. But, in runs fine on
the command line. I'm running 2.6.21-1.3194.fc7 on a IBM Thinkpad. I've
also tested on an IBM eServer running 2.6.9-55.ELsmp with the same
results. Fr
Paul Eggert wrote:
> + /* If we go one past the end, but that number prints the
> + same way "last" does, and prints differently from the
> + previous number, then print "last". This avoids problems
> + with rounding. For example, with the x86 it causes "seq
> +
Pádraig Brady <[EMAIL PROTECTED]> writes:
> The attached patch handles this by
> only counting signficant digits from the operands.
I'd rather use the idea I proposed earlier. Here's an implementation
of it, which works on all the test cases in your patch. In addition,
it works on the wilder co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please keep replies on the list, so that others may learn from this exchange.
According to Lyall Pearce on 6/22/2007 7:44 AM:
> Eric Blake wrote:
>> According to Lyall Pearce on 6/22/2007 7:22 AM:
>>> Using
>>> coreutils 6.9 (gentoo version is sys-ap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Lyall Pearce on 6/22/2007 7:22 AM:
> Using
> coreutils 6.9 (gentoo version is sys-apps/coreutils-6.9-r1)
> glibc 2.5 (gentoo version sys-apps/glibc-2.5-r3)
>
> env variable LANG=en_AU
>
> ls -la output intersperses .dot files amongst n
Using
coreutils 6.9 (gentoo version is sys-apps/coreutils-6.9-r1)
glibc 2.5 (gentoo version sys-apps/glibc-2.5-r3)
env variable LANG=en_AU
ls -la output intersperses .dot files amongst normal files, (see example
below)
When LANG=en, the ordering is as I expect, as per 'ls' info page,
alphabeti
15 matches
Mail list logo
