On Sunday 26 August 2007 16:00, Cristian Ionescu-Idbohrn wrote: > > > Embedded systems usualy place editable files on flash fs and those fs > > > get used out very much faster compared to real hdfs.
I think that sed creates new file, fills it and and then renames new file into old file so fast that first metadata update doesn't even have time to hit the disk storage before it's all done. What exactly are you trying to optimize out here? Why do you think your solution will be any different from what sed does now wrt storage wear? > > > IMO, a better > > > solution for such cases would be to place the temporary files on a > > > ramfs (usualy tmpfs) and overrite the original file at the end of the > > > editing session. This operation is indeed more complicated, but the > > > infrastructure is available (libbb/copy_file and libbb/remove_file.c). > > > Obviously this should be optional and configurable. > > > > > > What do you think? > > > > I think you mean > > > > sed ... <"$file" >/ramfs/tmp-$$ && mv /ramfs/tmp-$$ "$file" > > If one would prefer using mktemp (mkstemp) instead of tmp-$$, it would get > more complicated and inefficient. > > > This is what shells are for - to avoid bloating programs with all > > imaginable small improvements. > > But of course. That is one way to do it, but is it as efficient as having > sed do it in one go? What about combining sed and mv code to achieve the > same? Well, what about -R option - do it recursively over a directory? and -find_name '*pattern*' to act only on a subset of files? I don't like this kind of creeping featuritis. Does stock sed do this? -- vda _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
