Fabric

This looks like a duplicate of #32 :) If you’re running beta 1, getting the latest 0.9 checkout should have this issue fixed; I’ll also be releasing either Fab 0.9 final, or RC1, this weekend, so you could grab that as well.

Oh yes, and obviously if you do grab a newer version and the problem persists, reopen this or #32 and let me know.

I am coming back to original ticket I have opened before you told me that it was a duplicate of #32. I am attaching an updated version of my simple test. In this latest version the fabfile contains 2 tasks:

fab -l
Available commands:
task_local
task_subprocess

“task_local” use the fabric local api and “task_subprocess” uses subprocess.call. I do not understand why the 2 output are different. It is interesting to note that if the argument capture=False is passed to local the output is the same than subrocess.call.

This is complaint with this line in the doc :

If you need full interactivity with the command being run (and are willing to accept the loss of captured stdout) you may specify capture=False so that the subprocess’ stdout and stderr pipes are connected to your terminal instead of captured by Fabric.

However I still do not understand what you mean by and are willing to accept the loss of captured stdout. Could you please use the example to explain what is exactly captured or lost ?

Thank you for you help. Regards, —yml

Hi Yann,

First, apologies for the original duplicate ticket confusion, that was my mistake. It wasn’t clear to me at the time that you were using local so I thought you were seeing #32. Sorry!

Anyway, to explain the real issue:

• Subprocess allows you to change where the stdout and stderr pipes go when the local program runs;
• By default, as in subprocess.call, these pipes are attached to the calling terminal, so you (the user) see all the program’s output, just as if you had called it yourself in a shell.
• However, in this default case, Python has no way of reading or retaining the text from the program — it goes from the program to your terminal directly.
• In Fabric I had the need to capture the stdout of some programs, and so the capture keyword arg to local was born: it lets you toggle where the pipes get directed to.
• However, right now,capture is True by default, meaning that stdout gets captured and returned by local and stderr is attached to that return value as an attribute (this changed in master — in 0.9 stderr is discarded completely!)
• Some programs, like unittest, split their output between stdout and stderr depending on what’s going on (in this case, “print” lines inside tests go to stdout, and unittest’s own output goes to stderr)
• Thus, you are seeing “dropped output” because stdout gets captured and stderr gets discarded, and the “interesting stuff” was in stderr.
• So, you can rectify this by inspecting e.g. local('my program').stderr (or if you just want to see the output and do not need to process it, just specify capture=False and stderr will show up in your terminal again.

Partly due to my own recent experiences, and your struggles with the feature, I've decided it might be best to swap the default behavior of capture in the next version so that it does not capture by default — see #88 which I just opened a few minutes ago :) This won’t help your exact case as I see it (wasn’t aware of return value .stderr attribute, or it wasn’t documented obviously enough) but I think it’s better not to have this potentially confusing behavior be the default.

Let me know if there’s still something unresolved here.

Thank you for this detailled explanation and indeed I think that changing the default settings make more sense to me. I am glad that I have a much better understanding to what is going on.

I should be able to take advantage of this knowledge an fix the bug I had in fabric_factory. Regards, —yml