On Apr 1, 6:32 pm, Mark Wooding <[EMAIL PROTECTED]> wrote: > Paddy <[EMAIL PROTECTED]> wrote: > > Why not use the fileinput modules functionality to iterate over a file > > in-place,printing just those lines you want? > > From the Python 2.5 manual: > > : *Optional in-place filtering:* if the keyword argument `INPLACE=1' is > : passed to `input()' or to the `FileInput' constructor, the file is > : moved to a backup file and standard output is directed to the input > : file (if a file of the same name as the backup file already exists, it > : will be replaced silently). > > This behaviour is very dangerous. If the script fails half-way through, > it will leave the partially-written file in place, with the `official' > name. The change-over is not atomic, breaking other programs attempting > to read simultaneously with an update.
I've used this methodology all the time both explicitely writing utilities like that and using 'perl -p -i -e ...' theoretically there may be problems. In practice I have people transforming files in their own workarea, and have never been called to clear-up after such a failing. Although theoretically you can describe a method of failure, I take issue with you calling it 'very dangerous' without further qualification. > > Two almost-simultaneous updates will corrupt the file without a usable > backup. The first will back up the input file, and start writing. A > second will /replace/ the backup file with the partially-constructed > output of the first, and then start processing it; but since its input > is incomplete, it will produce incomplete output. Ahah - the qualification. The above would be dangerous, but the OP may find that his current flow, or a slight modification of it will make simultaneous updates unlikely and use of fileinput OK. If not, then other methods may have to be employed. It _is_ good to know the threat and do the analysis though. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
