Following a file, or cloning tail

[Gordon McMillan]

claird at starbase.neosoft.com (Cameron Laird) wrote in
<C311C39CF376029F.651A9619D7C71B72.66E09700B142DAB0 at lp.airnews.net>: 

>In article <8F62C20E2gmcmhypernetcom at 199.171.54.154>,
>Gordon McMillan <gmcm at hypernet.com> wrote:
>               .
>               .
>               .
>>The whole inode thing in that code is because it is a common Linux
>>idiom to rely on the fact that once a process has opened a file, said
>>file can be deleted by another process without the reading process
>>noticing. 
>>
>>This idiom is completely impossible on Windows, so there's no sense in 
>>checking whether a new file with the same name has now been created.
>>
>>So what'll it be - a portable version that's useless on Linux, or one
>>that spends half it's time checking for something that can't occur on
>>Windows 
>><wink>?
>>
>>on-Windows-once-you've-grabbed-the-tail-
>> you've-got-the-whole-damn-dog-ly y'rs
>>
>>- Gordon (who never uses popen on Windows anyway)
>
>It's a good question.
>
>Is tail(1) in POSIX?  I'm out of copies of POSIX documentation
>again ...

Apparently not...

>It's never been a difficult question for me.  I've ended up
>coding different tail functions (methods) for different pro-
>jects.  Am I committing redundancy in my coding?  Barely,
>and at a level with which I'm comfortable.  The general cat-
>egory here is, "ambiguously defined stuff where the ideas
>are so clear it's easier recoding them than trying to merge
>conflicting requirements/definitions."

I'll agree with that. And I'll point out that I wrote the [long ago 
snipped] code *instead* of using os.popen("tail -f...."), because I really 
didn't want yet another shell running, and because I would still have had 
to deal with the writing process moving on to a new inode.

>I most often need such a tail for log-scraping, and part of
>my tail implementations generally is *not* to do what you
>describe, but to stop reading the mv-ed i-node and pick up
>with a newly-created file (a log, in my case).  This illu-
>strates the ambiguity in tail's semantics.  I repeat:  I
>resolve the ambiguity by my knowledge of requirements spe-
>cific to a project.

Hmmm. We definitely are having a problem in communicating. That was the 
whole reason for the inode checking - so the "tail"ing process could move 
on to the new file.


>You and I might have a slight vocabulary clash.  My code
>often involves tests of os.name.  I think of the results
>as "a portable version", without embarrassment.  Perhaps
>your habit is to regard the same as *not* "pure" Python,
>and correspondingly "importable".

Oh no, I have no problem with that. I was just pointing out that besides 
the platform syntactic differences, there are also platform semantic 
differences (i.e., yet more ambiguity).

C'mon, Cameron. You *know* if we disagree, at least one of us has 
misunderstood ;-).

- Gordon