Dave.Scott at eu
Sep 3, 2011, 10:20 AM
Post #3 of 4
Looking back through the code history it seems that xe is saving and restoring console state as a workaround for a bug where a subprocess was inheriting the terminal, failing and leaving it in a bad state. We've tidied up our subprocess handling since then and I can no longer reproduce the original problem (the original report was from 2007)
Therefore I've removed this workaround from xe - see xen-api pull request 334. Assuming the change builds and passes basic tests, i'll merge to master. With this change "xe vm-list | less" works as I would expect.
Perhaps in the future we should make "xe" behave like "git" -- I like the way it detects that it's running on a terminal and runs the output through your configured pager.
On Sep 3, 2011, at 1:48 PM, "Mike McClurg" <mike.mcclurg [at] citrix> wrote:
> On 08/24/2011 09:16 AM, George Shuklin wrote:
>> Good day.
>> Found incredibly strange and amazing bug.
>> If this command issued:
>> echo $(xe host-list name-label=$(hostname) ) | cat
>> bash displays: + Stopped
>> I don't press Ctrl-Z, it happens by itself.
>> This works in bash, don't work in csh. This happens irregularly (2-3
>> times going background, 1-2 times not).
>> You can replace 'hostname' and 'cat' with any other commands - only xe
>> in middle does matter. If 'hostname' replaced by text bug not appear.
>> I could not say I really it bother me, but it really strange. What
> Yes, I've noticed this too. This has to do with the way that xe is
> grabbing the terminal. You may have also noticed this same problem when
> you pipe xe output to less. When you pipe to less, you have to hit enter
> after every keypress, instead of less recognising keypreses as they occur.
> You can work around this by doing something like this: 'cat /dev/null |
> xe <command> | less'.
> xen-api mailing list
> xen-api [at] lists
xen-api mailing list
xen-api [at] lists