Hi, I had a need recently to run a command with execCmd() and store it's output and error to a log file, while still receiving it in the calling code. Redirecting the error to output stream to have all in one stream is also useful feature. All this can be done in the calling code: a) On the shell level, by modyfing the command. This can be intentionally dangerous because things like quoting of arguments has to be considered and also could cause problems when wrappers (sudo, nice, ...) are used. b) By handling the writing to files in a code. This would add unnecessary code duplication in a long run. (I don't think I'm the only one who can see a potential in this.) Also for asynchronous process runs, when storing both stderr & stdout in one file, it requires polling and some stream magic. It would be better to have this done right and only once so it can be properly tested. That's why I think having it present in execCmd() ready for everyone's use is the best solution. Unfortunately it seems that the code is a) essential on many places in vdsm and b) not properly covered by tests. Which makes it hard to touch. Also apparently some refactoring is either planned or already underway. What is the situation about refactoring that code area? Anyone working on it? Do we have an estimation of time-frame for it? Any suggestions/ideas? Tomas -- Tomáš Golembiovský <tgolembi@redhat.com>