Your example is way different. You're operating on objects instead of return values. Rewriting what you gave:
using namespace UnixUtilities;
No object necessary. No storage necessary. For your example to work the object needs to store the result of each method call in some member variable. Why is that a bad thing? Because it's harder to reason about member variables (that could change) than return values (which will always be the same if there is no state).
The OO example works off of return values, and the next .method() is on the return value of the previous call. It's almost totally isomorphic to your example (calling a function with the output of another), and isn't even really very OO in and of itself.
Ah, of course. That's what I get for commenting when I'm tired. The only comment that I would make is that the dot notation is very OO, indicating the method on the right is a member of the class of the object on the left. The 'using namespace' in my code was used to indicate the methods I called were static, thereby decoupling them from a particular object.
You're right, the location the function/method lives is slightly different. When I said it wasn't really OO, it is because there's no data encapsulation going on. Just running methods on the output of another method. The line of code could belong in an OO system, but is not in itself OO.