- seek channelId offset ?origin?
% cat /tmp/mydata 1234567890abcdefghijklmnopqrstuvwxyz % set f [open "/tmp/mydata" "r+"] file3 % seek $f 20 % puts -nonewline $f "KLM" % close $f % cat /tmp/mydata 1234567890abcdefghijKLMnopqrstuvwxyz
But what if the file is not a plain ASCII file, but instead a binary file? Well, there are two trains of thought here. One is that, rather than inserting/replacing at various seek spots within the file the new data, one should be working in terms of the data structures within the file, to ensure that the changes do not result in an invalid file.The other approach is that if you know what you are doing, then do it. There is one difference however. Before the invocation of whatever output file is to be done, one needs to make certain that the file handle (the return value from open, etc.) is configured to work with binary data - otherwise, Tcl may attempt to apply character encoding changes to the outgoing data.
Is there supposed to be a difference in the seek/puts behavior based on varying the open access value between "r+, "w+" and "a+"?
A little fortune teller has another usage example with random seek.
[seek]ing past the end of a file has operating-system-specific consequences, including, in some cases, "gap-filling with nulls".
Is there supposed to be a difference in the seek/puts behavior based on varying the open access value between "r+, "w+" and "a+"?
A little fortune teller has another usage example with random seek.
[seek]ing past the end of a file has operating-system-specific consequences, including, in some cases, "gap-filling with nulls".