--- Chris Devers wrote: > Really?? > > In my experience, the `open` command immediately > returns control to the controlling process (the shell, > or whatever else invoked it (pine etc)) without > waiting for the `open`ed application to finish, or for > that matter even to finish launching.
Others have gone over briefly why your observations about `open` returning are correct, but why that's actually the root of the problem. The problem isn't that it takes too long to return, it's that it returns too quickly. The issue in general is race conditions. Because `open` returns so soon you have no idea when the other app will open the file let alone close it. If you delete the file right away it may be missing by the time the app is up and running; if you delete it after it's been opened but before it's been closed, the app may choose to "undelete" it for you by saving it or whatnot. The only real way around this problem is to wait for the app to close and only then delete the file, and the only way to get that information without race conditions itself is from the OS itself. You'll want the new process to be a child process so you can know definitively that it has completed (and without constantly polling the process table). system() does this, though you'll want to launch the app directly rather than using something like `open` to open it indirectly. Since terminated processes can't have open files you can be sure that once the child finishes, the file is closed (or at least closed as far as your program is concerned, other processes out there in the universe may muck with your plans to delete it, but you have no control over that). In short, `open` is an awesome utility that I wish all *nices had, but it's not the right tool for this job. Live well, ~wren __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
