Well, you guys are the experts. I was trying to be smart - thinking that
lbracket 'required' the closing right bracket to keep the shell syntax
checkers happy. Maybe I am expecting too much from my shells need to check
syntax.
FYI - It seems to be working as expected, rather designed - so I shall
$ ./seq --version | head -1
seq (GNU coreutils) 8.22.119-8a51b
./seq -0 n works fine when n is a single digit:
$ ./seq --separator=, -0 5
-0,1,2,3,4,5
But something weird happens when one uses a number = 10:
$ ./seq --separator=, -0 10
On 06/18/2014 10:41 AM, Rasmus Villemoes wrote:
$ ./seq --version | head -1
seq (GNU coreutils) 8.22.119-8a51b
./seq -0 n works fine when n is a single digit:
$ ./seq --separator=, -0 5
-0,1,2,3,4,5
But something weird happens when one uses a number = 10:
$ ./seq --separator=, -0 10
On 06/18/2014 02:19 AM, Bernhard Voelker wrote:
On 06/17/2014 06:03 PM, Pádraig Brady wrote:
From 0a4b8027049f6746a237c9fc34a0e0a4afdcfc62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Wed, 4 Jun 2014 00:09:11 +0100
Subject: [PATCH] df: output
On 06/18/2014 01:03 PM, Pádraig Brady wrote:
On 06/18/2014 10:41 AM, Rasmus Villemoes wrote:
$ ./seq --version | head -1
seq (GNU coreutils) 8.22.119-8a51b
./seq -0 n works fine when n is a single digit:
$ ./seq --separator=, -0 5
-0,1,2,3,4,5
But something weird happens when one uses a
On 06/18/2014 03:39 PM, Pádraig Brady wrote:
Subject: [PATCH] seq: fix incorrect output with start or end of -0
LGTM - although I'm still wondering what's the use case
behind a negative Null -0. ;-)
Thanks have a nice day,
Berny
On 06/18/2014 01:09 PM, Pádraig Brady wrote:
On 06/18/2014 02:19 AM, Bernhard Voelker wrote:
On 06/17/2014 06:03 PM, Pádraig Brady wrote:
From 0a4b8027049f6746a237c9fc34a0e0a4afdcfc62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Wed, 4 Jun 2014
revisted my 8.15 package in detail. Seems that two years ago I had already
done something special for coreutils - so my apology - not a bug, just
something in the way. I will find a way to make it transparent for installp.
My question: once done, would you be interested in what I have done to
Curious why you are calling this a compiler bug. I am not a POSIX nerd, but
it looks as if the old code was compiler independent, and now it is
dependent on something.
Just one difference in od.c that shows a change in identifer conventions.
What is the origin of the _GL_* identifiers? Unix or
I am confused by what is in git regarding ftoastr.h
The enum code has been around forever and not caused a problem. I think
the problem lies elsewhere because version 8.20 builds fine.
root@x093:[/data/prj/gnu/coreutils]diff ./coreutils-8.22/lib/ftoastr.h
./coreutils-8.15/lib/ftoastr.h
3c3
Bernhard Voelker m...@bernhard-voelker.de writes:
On 06/18/2014 03:39 PM, Pádraig Brady wrote:
Subject: [PATCH] seq: fix incorrect output with start or end of -0
LGTM - although I'm still wondering what's the use case
behind a negative Null -0. ;-)
I agree it is unlikely anyone would write
So, having looked at the -E output of the compiles I guess it has something
to do with how enum defines it results. And how that gets parsed here:
Goes over my head in any case.
#define _GL_FLOAT_STRLEN_BOUND_L(t, pointlen) \
(1 + _GL_##t##_PREC_BOUND + pointlen + 1
Michael Felt wrote:
Curious why you are calling this a compiler bug.
Because it is a compiler bug. Try to compile (but not link) the
attached file. Here's what I get on AIX 7.1 with xlc 12.1 and GCC 4.8.1.
$ gcc -c xlcbug1.c
$ xlc -c xlcbug1.c
xlcbug1.c, line 22.39: 1506-045 (S)
13 matches
Mail list logo
