Timeline for Is there a way to modify a file in-place?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 27, 2016 at 21:58 | comment | added | camh | @AlexanderMills There is no "replacement" in the requirements, just filtering. i.e. select lines that match a pattern and overwrite the source file with lines matching the pattern from the same file. Not sure about your "file truncated" error. The program does not output that text (unless you've truncated the error message), so it's not the overwrite program outputting that. | |
| Dec 25, 2016 at 21:15 | comment | added | Alexander Mills | I am getting stderr "file truncated" => I thought the whole point of this was to avoid truncating files? | |
| Dec 25, 2016 at 21:14 | comment | added | Alexander Mills | 'grep pattern bigfile | overwrite bigfile' - I got this working without errors, but what I don't understand is - isn't the requirement to replace what's in the pattern with some other text? so shouldn't it be something like: 'grep pattern bigfile | overwrite /replace-text/ bigfile' | |
| Jul 20, 2011 at 1:25 | history | edited | camh | CC BY-SA 3.0 |
Added public domain notice
|
| Apr 12, 2011 at 11:27 | history | edited | camh | CC BY-SA 3.0 |
added 2 characters in body
|
| Apr 11, 2011 at 21:24 | comment | added | Gilles 'SO- stop being evil' |
Nice. This may be a valuable addition to Joey Hess's moreutils. You can use dd, but it's cumbersome.
|
|
| Apr 11, 2011 at 13:45 | comment | added | camh |
@Arcege: Writing is not done in blocks. If your read process has read 2 bytes and your write process writes 1 byte, only the first byte will change and the read process can continue reading at byte 3 with the original contents at that point unchanged. Since grep will not output more data than it reads, the write position should always be behind the read position. Even if you are writing at the same rate as reading, it will still be ok. Try rot13 with this instead of grep, and then again. md5sum the before and after and you'll see its the same.
|
|
| Apr 11, 2011 at 13:15 | comment | added | Arcege | +1 for C; does seem to work, but I see a potential problem: the file is being read from the left side at the time as the right is writing to the same file and unless you coordinate the two processes, you would have overwrite problems potentially on the same blocks. It might be better for the file integrity to use smaller block size since most of the core tools will likely use 8192. This might slow down the program enough to avoid conflicts (but cannot guarantee). Maybe read larger portions into memory (not all) and write in smaller blocks. Could also add a nanosleep(2)/usleep(3). | |
| Apr 11, 2011 at 13:06 | vote | accept | Nim | ||
| Apr 11, 2011 at 13:06 | comment | added | Nim | I wanted to see if I could get away without writing something for it! :) I guess this will do the trick! Thanks! | |
| Apr 11, 2011 at 12:09 | history | edited | camh | CC BY-SA 3.0 |
oh noes. one line too many
|
| Apr 11, 2011 at 12:01 | history | answered | camh | CC BY-SA 3.0 |