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.