On Mon, 31 Oct 2005, Theodoros V. Kalamatianos wrote:
I was thinking to have the following:
bseek=BYTES skip BYTES bytes at start of output\n\
bskip=BYTES skip BYTES bytes at start of input\n\
obseek=M[,N] skip M bytes at start of each output block and N bytes after
ibskip=M[,N] skip M bytes at start of each input block and N bytes after
I found the *tail names too long for day-to-day usage. Perhaps if we could
find a shorter name, I could drop the second numeric argument in favour of a
separate option.
It seems like a reasonable addition to me, though someone would have
to write it. The documentation would be the hard part, I think.
Well, I am in the process of writing some proof-of-concept code right now. As
for the documentation...ehmm...ummm...emm... :-)
Well, I have a piece of code in testing right now. What I'd like to ask is
what would be the expected behaviour from obseek when writing the last
output block.
While there is no problem with the seeking before the block, I find myself
in a dilema regarding the seeking afterwards. If the last output block is
not obs-sized I think it is logical to asume that no seeking/padding
should happen afterwards. But I am not sure what should happen if the
block is obs-sized (i.e. a full output block).
To seek/pad the output lseek is not enough - you have to actually write
something for the file to expand to the new size. I believe that the
expected behaviour would be to expand the file, even if there is no more
data to be written after the seek. Perhaps this should be an extra oflag ?
What do you think ?
Regards,
Theodoros Kalamatianos
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
