On Tue, Jul 5, 2016 at 10:44 AM, Yaniv Bronheim <ybron...@redhat.com> wrote:
> Hi > I do work to remove the cpopen usages from execCmd. Using std popen over > py3 and subprocess32 over py2 which both implements the same api. The only > gap is the output object for async calls that we need to align with the > standard implementation and modify our current usages. I don't think that > adding more non-standard logics to execCmd is a good idea. we should fit > the standard usage in this function or override it separately with specific > implementation in commands.py. You may propose such patch > > On Fri, Jul 1, 2016 at 5:43 PM, Tomáš Golembiovský <tgole...@redhat.com> > wrote: > >> 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? >> >> btw, after examine the area again, isn't watchCmd func is what you describe? we just need to replace the asyncProc usages there with something that doesn't use StringIO as we do to support py3 >> Tomas >> >> -- >> Tomáš Golembiovský <tgole...@redhat.com> >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel > > > > > -- > *Yaniv Bronhaim.* > -- *Yaniv Bronhaim.*
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
