Re^2: launch long running background program and watch final progress

If you are waiting for some file to change, then some variant of inotify will tell you the file changed without looping continuously in a tail loop burning Mips to not much effect. You can also get notified if a directory changes, some new file appears, perhaps some long awaited "I am finished and ready for business" file.

Update: I suppose also if you opened the file for read, then while(<FILE>)... will cause a program pause in the OS waiting for the next line to appear. You can examine each line waiting for the right msg to be written. Of course this could "deadlock" if the if the other program hangs. But if it dies and file closes, then you should get an EOF. The basic rationale behind these 2 ideas is not burn a lot of Mips waiting for something that itself is burning a lot of Mips where your "watcher" slows things down. I haven't tested, but I don't think you get an EOF if somebody else has the file open for "write". I have used inotify before and that will work.

Update: eatingmyownwords = I now think that that this won't work unless you are using some sort of trick like Tee and reading from a pipe which is left open. I think you get EOF when you reach the current extent of text in the file whether it is open or not for additional writes - that's what tail does.

Comment on Re^2: launch long running background program and watch final progress

Replies are listed 'Best First'.
Re^3: launch long running background program and watch final progress by Anonymous Monk on Apr 22, 2016 at 19:29 UTC
So, are you saying my File::Tail approach is OK? Or is there some way that is better? I'm totally open to doing in whichever way is best...the approach I took was simply to "git 'er done"...certainly not because I was positive it was the most elegant solution...	[reply]
Re^4: launch long running background program and watch final progress by Marshall (Canon) on Apr 22, 2016 at 20:02 UTC
Well "what works" is good! I'm not saying that it isn't. If you are waiting for something that might take an hour clock time, who the heck cares if you get an immediate answer? And probably some burned Mips doesn't matter at all? file tail is a polling routine that adjusts its time to the next poll. Fine. Using inotify doesn't involve any polling and therefore a) it is "faster in clock time" and b) uses less Mips to monitor what you want. What is "best" is very subjective and depends upon the application. I am not judging "right or wrong". I am merely suggesting other ways, which is what I think that you asked for? I don't think that there is a single "right way". There are multiple ways. Whatever achieves the objective is "good". I guess this depends upon what the objective is and how you measure it?	[reply]