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

[Jérémy Compostella]

> 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 ?

Jérémy