Paul Gilmartin wrote: > I would be delighted if that happened. In a case that I can't > reproduce in a simple test, it was leaving the original file > unmodified.
It could have been as simple as having filemode A accessed R/O. Understanding commitment isn't really the problem here. The basic idea is simple: If a device driver can't start, the pipeline won't run. The problem is that a nonzero return code doesn't necessarily tell you whether the pipeline ran or not. PIPE (end /) < FOO BAR A | state | > FOO FOUND A You have to know the specific return codes to figure out what happened here--in particular, that the file drivers have their own return codes for when the file doesn't exist and will never return 28 or 36. So if you get rc 0, 28, or 36, you know the pipeline ran OK. If you get 119 (filemode not available) or 146 (file not found), it's from < or > and you know the pipeline didn't run at all. But what about rc 20 (invalid character in fileid)? Did < stop before the pipeline ran at all, or did STATE stop when it got to a bad name in the list? Either way, FOO FOUND may not contain what you want, but you don't know if an old file was erased or not. ¬R
