Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
How to capture output of programs that use alternate mode #2404
then select an entry in the
and will obtain what you selected.
In xonsh, this doesn't work:
How to do this?
Is it possible that this is just a bug?
The docs say:
But in bash
$ echo $(bash -c '(>&2 echo "error")')
In bash this prints
Another indication that this might be a bug is that the function that implements
Hey @nh2, thanks for reporting! Can you please paste the output of
> $OUTPUT = $(git branch | fzf) > $OUTPUT ' master\n'
Not sure about those leading spaces, but the trailing newline is the expected behavior of xonsh grabbing output from something.
For your second comment, instead of doing
you can do
@gforsyth Ah, it actually works for you? For me it just hangs, not showing any output, as in the paste above.
FWIW, I'm having some very similar issues.
Capturing the output of fzf actually breaks my terminal such that I can't highlight text, or interact with it via my mouse at all. If I run xonsh with readline instead of prompt_toolkit, then mouse interaction causes tty scruft to start getting printed to the screen. I'm not sure which specific changeset introduced this, but I've figured out that this started happening in 0.5.5. If I run fzf again without capturing it and ^C it, then my terminal returns to normal.
Also, capturing fzf output sometimes works, e.g. I'm selecting master in both invocations below:
In case it's relevant, I've tried this with both readline and prompt_toolkit, same result. I've gone back a couple of releases and this has been present in all of them for me.
EDIT: If it's any consolation to people who want to be able to use something in the meantime, I've found that neither of my issues occur with https://github.com/garybernhardt/selecta or https://github.com/rschmitt/heatseeker, so I'm just going to migrate to using one of these. I'm still happy to help out with debugging the issues I've found though.
I've got two potential fixes for my issues, one of which might also fix your issues, @nh2. Would you be willing to try applying this patch, and see if it works for you?
index eef3d933..8e218a44 100644 --- a/xonsh/built_ins.py +++ b/xonsh/built_ins.py @@ -741,7 +741,7 @@ def _update_last_spec(last): elif ON_WINDOWS and not callable_alias: last.universal_newlines = True last.stderr = None # must truly stream on windows - else: + elif captured != 'stdout': r, w = pty.openpty() if use_tty else os.pipe() _safe_pipe_properties(w, use_tty=use_tty) last.stderr = safe_open(w, 'w')
This changes things such that the final process in a spec won't have its stderr captured unless the capture mode indicates it should be, which should be closer in behaviour to what more traditional shells do, and matches the documentation for
My other patch is a little more involved and is more of a workaround than a fix, so I'm more interested in this one first, as it takes xonsh in the right direction (IMO).
If one of the fantastic Xonsh devs could weigh in on whether or not this tiny patch is acceptable, that'd be good! I'm happy to write up some tests for it and submit a PR. I've found a good work around is to throw tee on the end, e.g.
@nathan-hoad I tried your patch, it does seem to bring an improvement but also breaks something else:
Before your patch:
after your patch:
Huh, interesting! I don't experience that behaviour. Is
What OS + terminal are you using? If I can try to match your setup, I might be able to replicate it.
Yes, it seems so, if I do
Ubuntu 16.04 and
But I think it was just that the state of that terminal was broken. Retrying it now and it works. In
So I need to revise my answer, your patch seems to have have the desired result for me.