bug#13391: dd silently ignores lseek error
From ea524ab7388bb35e591dcdb0fc7f7989d61143ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com 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.
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#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#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
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=seqmanpath=FreeBSD+9.0-RELEASE
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
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 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
