coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dd: add 'skip_bytes' and 'count_bytes' operands


From: Jérémy Compostella
Subject: Re: dd: add 'skip_bytes' and 'count_bytes' operands
Date: Wed, 8 Feb 2012 19:19:51 +0100

First, thank you  Eric for the explanation and the guidance.

[...]
> On 02/08/2012 03:14 PM, Jérémy Compostella wrote:
> Not too bad. A variation to tagging the number directly, would be to
> add flags:
>  iflag=skip_bytes # Treat skip as number of bytes not blocks
>  iflag=count_bytes # Treat count as number of bytes not blocks
>  oflag=seek_bytes # Treat seek as number of bytes not blocks
> While cleaner it's a bit less direct.  Though since this is slightly
> off the main use case, I guess flags are OK.
I think too. Moreover, IMHO the "_bytes" and "KB_bytes" suffixes are not
really natural and although flags are indirect it looks clearer with
flags. I will re-write my patch with the flags solution.

> > 2. Do you know if there is a utility function somewhere in coreutils
> > or gnulib which could help me to parse this ? If such a function
> > exists it could be able to manage more units (bytes, kbytes,
> > megabytes, ...). If have to write such a function we have to discuss
> > the possibilities I have to provide.
> All was done already. See parse_integer().
OK. I will take a look for my personal interest.

[...]
> Sorry for the churn on this, but I've not had time to think about it
> and I'm just reacting to your questions on the fly.  At least the
> decision process for the interface is documented.
It's absolutely not a problem for me to examine all the solutions even
losing time with the bad one. If you directly provided me the
appropriate solution I probably would not take time to look at the
legacy and POSIX constraints what would be a shame for me. And since I
do it on my pretty small free time and just for the pleasure, I'm not in
a hurry long and reasonable long discussion is not a problem at all.

Jérémy


reply via email to

[Prev in Thread] Current Thread [Next in Thread]