I'm using 0.9. But if you're not seeing this, then perhaps it is something specific to my mac OSX install. I'll try reproducing it using a different unix flavor to run fabric and will let you know if I see it there also.
On Thu, Feb 11, 2010 at 11:05 AM, Jeff Forcier <j...@bitprophet.org> wrote: > Hi Simon, > > What version of Fabric are you using? I haven't heard any complaints > about this for some time so I'm hoping the issue has been resolved. I > assume it's the same issue as this one: > > http://code.fabfile.org/issues/show/32 > > which looks to have been solved with a patch that landed prior to > 0.9.0's release. If you're using 0.9.0 and still encountering the > problem, let me know and we can continue. > > Best, > Jeff > > On Thu, Feb 11, 2010 at 10:53 AM, Simon Smith <simongsm...@gmail.com> > wrote: > > Hi - > > > > I'm seeing that whenever I do (via fabric) run("ls") on a remote system, > I > > often don't get the last line of output (I do get the output if it is > just > > one line)... I can work around it by doing "ls && echo" (i.e. every time > I > > care about the output, I'll need to do this) but it seems like quite a > hack > > for a very basic and important piece of functionality. > > > > > > I can reproduce this with other commands, like run("cat /some/file"). > > > > When I manually run this, e.g. "ssh remotehost ls" I get all of the > output. > > > > Am I missing something basic here, or is my issue the same as the one > below > > or a different bug? > > > > > > Simon > > > > > > > >> Jeff Forcier wrote: > > > > We've gone back and forth on that particular race condition a number > > of times at this point, unfortunately, so I'm not convinced that this > > change won't introduce other problems. If you dig through the history > > of Fabric from 0.1.1 backwards, looking at > > fabric.py::_start_outputter(), you'll see what I'm talking about. (I > > don't _think_ I changed that part of the code when I created > > magic-removal/0.9; certainly it is by and large untouched.) > > > > I'd be happy if it was this simple but as I said, we've been burned a > > number of times when tweaking this particular chunk of code, so I am > > loathe to just slap another patch on. > > > > -Jeff > > > > On Tue, May 26, 2009 at 4:10 PM, Evan Jones <addr...@hidden> wrote: > >> Jeff Forcier wrote: > >>> > >>> In the meantime, though, as I said -- if you could try switching your > > > >>> host list around, or simply running this a number of times in a row > >>> and see if any obvious patterns appear, that might help. Feel free to > >>> throw debug statements into fabric.network.output_thread() to see what > > > >>> might be going on, too, as that's inevitably how I'll be debugging on > >>> my end if I need to :) > >> > >> channel.recv_exit_status() can return before output gets written. In > fact, > > > >> tracing Paramiko, the message saying "exit status = x" *always* arrives > >> before the message saying "output = y". The main thread then calls > >> channel.close(), which discards any future output. So this is basically > a > > > >> classic thread race condition. The attached patch fixes this. > >> > >> Evan > >> > >> -- > >> Evan Jones > >> http://evanjones.ca/ > > > >> > >> > >> > > > > _______________________________________________ > > Fab-user mailing list > > Fab-user@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/fab-user > > > > > > > > -- > Jeff Forcier > Unix sysadmin; Python/Ruby developer > http://bitprophet.org >
_______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
