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

[Pádraig Brady]

On 02/07/2012 06:25 PM, Jérémy Compostella wrote:
>> On 02/06/2012 03:24 PM, Jérémy Compostella wrote:
>> >> Hmm, shouldn't there be a seek_bytes param too for consistency?
>> > That was effectively my first mail question. As you talk about it in
>> > your explanation addition in coreutils.texi I guess I should start
>> > implementing it ?
>> 
>> I think so.
>> 
>> Note it annoys me to be adding 3 new options to dd,
>> though I can't think of how to simplify off hand.
>> Anyway if we do think of a better way it will probably only
>> involve minor interface code changes.
> Today, I thought about it a little bit and I did not find a veritable
> good solution. The only one I thought about was introducing a "modal"
> (bytes or block) option but it will probably add more complexity in both
> code and documentation.
> 
>> >> This additional doc change is necessary I think:
>> >> --- a/doc/coreutils.texi
>> >> +++ b/doc/coreutils.texi
>> >> @@ -8354,8 +8354,10 @@ should not be too large---values larger than a few 
>> >> megabytes
>> >>  are generally wasteful or (as in the gigabyte..exabyte case) downright
>> >>  counterproductive or error-inducing.
>> >>
>> >> -Use different @command{dd} invocations to use different block sizes for
>> >> -skipping and I/O@.  For example, the following shell commands copy data
>> >> +To use different block sizes for skipping and I/O@
>> >> +you can use the @samp{skip_bytes} and @samp{seek_bytes} options,
>> >> +or the traditional method of separate @command{dd} invocations.
>> >> +For example, the following shell commands copy data
>> >>  in 512 KiB blocks between a disk and a tape, but do not save or restore a
>> >>  4 KiB label at the start of the disk:
>> > OK. I would add something about count_bytes too, no ?
>> 
>> Well this example was just about skipping,
>> but it's probably best to mention all related args there.
>> How about:
>> 
>> "
>> To process data that is at an offset or size that is not a
>> multiple of the I/O@ block size, you can use the @samp{skip_bytes},
>> @samp{seek_bytes} and @samp{count_bytes} options.  Alternatively
>> the traditional method of separate @command{dd} invocations can be used.
>> For example, the following shell commands copy data
>> "
> It looks fine to me.
> 
>> 
>> > Should I import your patch suggestions in my patch or do you will make
>> > an additional commit on top of it ? That's particularly relevant if I
>> > implement the seek_bytes operand.
>> 
>> It's best if we can --amend everything into your patch.
> OK.
> 
> I thought a little bit more about the mutually exclusive bytes and not
> bytes operands. Indeed, we could let the user use both bytes and not
> bytes operands simultaneously in a cumulative way (for example
> seek_bytes and seek operands in the dd call). The corresponding code
> should not be hard to write and it could offer more
> flexibility. However, it could be more confusing for the user and the
> documentation should explain this behavior. Since you explain me that we
> have to keep options and documentation as simple as possible, I'm not
> sure it's a so good idea. What is your opinion about this ?

I considered that, but I think your initial implementation is fine.
I.E. mutually exclusive is fine.  I can't see a need to use
both methods to skip and count.

That leads onto the only other possible implementation I suppose.
I.E. since we don't need to specify skip and skip_bytes together,
the option value could select between each mode. I.E.

skip=2      => skip    2 blocks,
skip=2b     => skip 1024 blocks,
skip=2bytes => skip    2 bytes

Hmm, that's not too bad at all really.

cheers,
Pádraig.