Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: API

strange bug with xe and bash

 

 

Xen api RSS feed   Index | Next | Previous | View Threaded


george.shuklin at gmail

Aug 24, 2011, 1:16 AM

Post #1 of 4 (376 views)
Permalink
strange bug with xe and bash

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?

Tested on XCP 0.5 and XCP 1.0


_______________________________________________
xen-api mailing list
xen-api [at] lists
http://lists.xensource.com/mailman/listinfo/xen-api


mike.mcclurg at citrix

Sep 3, 2011, 5:48 AM

Post #2 of 4 (335 views)
Permalink
Re: strange bug with xe and bash [In reply to]

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 [at] lists
http://lists.xensource.com/mailman/listinfo/xen-api


Dave.Scott at eu

Sep 3, 2011, 10:20 AM

Post #3 of 4 (332 views)
Permalink
Re: strange bug with xe and bash [In reply to]

Hi,

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.

Cheers,
--
Dave Scott

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: [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 [at] lists
> http://lists.xensource.com/mailman/listinfo/xen-api

_______________________________________________
xen-api mailing list
xen-api [at] lists
http://lists.xensource.com/mailman/listinfo/xen-api


mike.mcclurg at citrix

Sep 3, 2011, 10:21 AM

Post #4 of 4 (334 views)
Permalink
Re: strange bug with xe and bash [In reply to]

On 09/03/2011 06:20 PM, Dave Scott wrote:
> Hi,
>
> 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.
Awesome!
> 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.
>
Yes, I second this ;)

_______________________________________________
xen-api mailing list
xen-api [at] lists
http://lists.xensource.com/mailman/listinfo/xen-api

Xen api RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.