This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] strange bug with xe and bash

To: Mike McClurg <mike.mcclurg@xxxxxxxxxx>
Subject: Re: [Xen-API] strange bug with xe and bash
From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Date: Sat, 3 Sep 2011 18:20:47 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 03 Sep 2011 10:20:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E62221B.8040004@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <1314173793.4656.8.camel@mabase> <4E62221B.8040004@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxqXbx1tfph5USuRrCAzxVxuBunkg==
Thread-topic: [Xen-API] strange bug with xe and bash

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.

Dave Scott

On Sep 3, 2011, at 1:48 PM, "Mike McClurg" <mike.mcclurg@xxxxxxxxxx> 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: [1]+  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
>> happens?
> 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'.
> Mike
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api

xen-api mailing list

<Prev in Thread] Current Thread [Next in Thread>