bug#13394: Misalignment for "seq -w"
On 01/09/2013 01:05 PM, Pádraig Brady wrote: > Looks like a bug. I'll fix with: > > diff --git a/src/seq.c b/src/seq.c > index e1b467c..3eb53f8 100644 > --- a/src/seq.c > +++ b/src/seq.c > @@ -332,6 +332,8 @@ get_default_format (operand first, operand step, operand > last) > last_width--; /* don't include space for '.' */ > if (last.precision == 0 && prec) > last_width++; /* include space for '.' */ > + if (first.precision == 0 && prec) > +first_width++; /* include space for '.' */ > size_t width = MAX (first_width, last_width); > if (width <= INT_MAX) > { +1 Have a nice day, Berny
bug#13394: Misalignment for "seq -w"
On 01/09/2013 01:05 PM, Pádraig Brady wrote: On 01/09/2013 11:01 AM, Erik Auerswald wrote: Hi, On 01/09/2013 11:34 AM, Bernhard Voelker wrote: On 01/09/2013 11:14 AM, Marcel Böhme wrote: There are the following problems with the -w parameter of the seq tool: [...] Hmm, according to the TEXI manual, the FIRST number should also use a fixed point decimal representation when the -w option is used: [...] But that leaves the question open if there's a reason for this. I.e. if it's just documented behavior, a requirement of some standard or due to compatibility reasons. That seems to be just documented behavior, since seq is not standardized by POSIX and other seq implementations ([1],[2],[3]) don't document this. On the contrary, a common example is 'seq -w 0 .05 .1'. This example works fine with GNU seq: $ seq -w 0 .05 .1 0.00 0.05 0.10 Even when counting to negative numbers: $ seq -w 0 -.05 -.1 00.00 -0.05 -0.10 Starting with a negative number with a fractional step size breaks equal width for non-negative numbers: $ seq -w -1 .5 1 -1.0 -0.5 0.0 0.5 1.0 $ seq --version | head -n1 seq (GNU coreutils) 8.13 Looks like a bug. I'll fix with: diff --git a/src/seq.c b/src/seq.c index e1b467c..3eb53f8 100644 --- a/src/seq.c +++ b/src/seq.c @@ -332,6 +332,8 @@ get_default_format (operand first, operand step, operand last) last_width--; /* don't include space for '.' */ if (last.precision == 0 && prec) last_width++; /* include space for '.' */ + if (first.precision == 0 && prec) + first_width++; /* include space for '.' */ size_t width = MAX (first_width, last_width); if (width <= INT_MAX) { The patch looks plausible. ;-) Thanks, Erik
bug#13394: Misalignment for "seq -w"
On 01/09/2013 11:01 AM, Erik Auerswald wrote: Hi, On 01/09/2013 11:34 AM, Bernhard Voelker wrote: On 01/09/2013 11:14 AM, Marcel Böhme wrote: There are the following problems with the -w parameter of the seq tool: [...] Hmm, according to the TEXI manual, the FIRST number should also use a fixed point decimal representation when the -w option is used: [...] But that leaves the question open if there's a reason for this. I.e. if it's just documented behavior, a requirement of some standard or due to compatibility reasons. That seems to be just documented behavior, since seq is not standardized by POSIX and other seq implementations ([1],[2],[3]) don't document this. On the contrary, a common example is 'seq -w 0 .05 .1'. This example works fine with GNU seq: $ seq -w 0 .05 .1 0.00 0.05 0.10 Even when counting to negative numbers: $ seq -w 0 -.05 -.1 00.00 -0.05 -0.10 Starting with a negative number with a fractional step size breaks equal width for non-negative numbers: $ seq -w -1 .5 1 -1.0 -0.5 0.0 0.5 1.0 $ seq --version | head -n1 seq (GNU coreutils) 8.13 Looks like a bug. I'll fix with: diff --git a/src/seq.c b/src/seq.c index e1b467c..3eb53f8 100644 --- a/src/seq.c +++ b/src/seq.c @@ -332,6 +332,8 @@ get_default_format (operand first, operand step, operand last) last_width--; /* don't include space for '.' */ if (last.precision == 0 && prec) last_width++; /* include space for '.' */ + if (first.precision == 0 && prec) +first_width++; /* include space for '.' */ size_t width = MAX (first_width, last_width); if (width <= INT_MAX) {
bug#13394: Misalignment for "seq -w"
Hi, On 01/09/2013 11:34 AM, Bernhard Voelker wrote: On 01/09/2013 11:14 AM, Marcel Böhme wrote: There are the following problems with the -w parameter of the seq tool: [...] Hmm, according to the TEXI manual, the FIRST number should also use a fixed point decimal representation when the -w option is used: [...] But that leaves the question open if there's a reason for this. I.e. if it's just documented behavior, a requirement of some standard or due to compatibility reasons. That seems to be just documented behavior, since seq is not standardized by POSIX and other seq implementations ([1],[2],[3]) don't document this. On the contrary, a common example is 'seq -w 0 .05 .1'. This example works fine with GNU seq: $ seq -w 0 .05 .1 0.00 0.05 0.10 Even when counting to negative numbers: $ seq -w 0 -.05 -.1 00.00 -0.05 -0.10 Starting with a negative number with a fractional step size breaks equal width for non-negative numbers: $ seq -w -1 .5 1 -1.0 -0.5 0.0 0.5 1.0 $ seq --version | head -n1 seq (GNU coreutils) 8.13 HTH, Erik [1] http://man.cat-v.org/unix_8th/1/seq [2] http://man.cat-v.org/plan_9/1/seq [3] http://www.freebsd.org/cgi/man.cgi?query=seq&manpath=FreeBSD+9.0-RELEASE
bug#13394: Misalignment for "seq -w"
On 01/09/2013 11:14 AM, Marcel Böhme wrote: > Dear all, > > There are the following problems with the -w parameter of the seq tool: > > $seq -w -1 1.0 0 > -1.0 > 0.0 > 1.0 > > But it should print: > -1.0 > 00.0 > 01.0 Hmm, according to the TEXI manual, the FIRST number should also use a fixed point decimal representation when the -w option is used: `-w' `--equal-width' Print all numbers with the same width, by padding with leading zeros. FIRST, STEP, and LAST should all use a fixed point decimal representation. (To have other kinds of padding, use `--format'). Thus, seq is just doing what the manual says: $ seq -w -1.0 1.0 0.0 -1.0 00.0 But that leaves the question open if there's a reason for this. I.e. if it's just documented behavior, a requirement of some standard or due to compatibility reasons. But as Padraig worked in this area recently ([1]), I think there is further room for improvement ... and then the documentation should be fixed. @Padraig: WDYT? Have a nice day, Berny [1] http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=64d4a280
bug#13394: Misalignment for "seq -w"
Dear all, There are the following problems with the -w parameter of the seq tool: $seq -w -1 1.0 0 -1.0 0.0 1.0 But it should print: -1.0 00.0 01.0 A similar problem is observable for: $seq -w 10 -.1 1 | head Best regards, Marcel
bug#13391: dd silently ignores lseek error
On 01/09/2013 07:36 AM, Bernhard Voelker wrote: why not check input_seekable where it is set - ~60 lines above? I was trying to keep related code together. Thanks for all the reviews, which I've fixed locally. To provide an argument for why this shouldn't go in, the following is equivalent: python -c 'import os; os.lseek(0,0,os.SEEK_CUR)' 2>/dev/null < /the/file && dd if=/the/file ... So if the need is esoteric enough the above might suffice? I'll leave it stew for a while longer. thanks, Pádraig.
bug#13391: dd silently ignores lseek error
From ea524ab7388bb35e591dcdb0fc7f7989d61143ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Wed, 9 Jan 2013 00:42:38 + Subject: [PATCH] dd: add [io]flag=seekable to verify file support for lseek * src/dd.c: Add the new O_SEEKABLE flag. (main): Verify leek() works if O_SEEKABLE is set. leek? (usage): Describe the new flag. * tests/dd/misc.sh: Augment the test for the new options. * doc/coreutils.texi (dd invocation): Describe the new option. * cfg.mk (sc_dd_O_FLAGS): Add O_SEEKABLE to the list of private flags with a a single underscore. * NEWS: Mention the new feature.