Bug #99

Color reset litters information on onehost list ( onevm function list_short and header_host_small involved). Onevm the same

Added by Marlon Nerling almost 10 years ago. Updated almost 10 years ago.

Status:ClosedStart date:04/17/2009
Priority:NormalDue date:
Assignee:Javi Fontan% Done:

0%

Category:CLI
Target version:Release 1.2.1
Resolution:fixed Pull request:
Affected Versions:

Description

The first line of a onevm/onehost list ist littered with the shell color reset:
$ vmhost -l name list | cat -A
[[1m[[4mNAME $
^[[0m172.22.0.2 $
172.22.0.4 $
172.22.0.5 $
172.22.0.7 $
172.22.0.8 $
172.22.0.9 $
..

This is really nasty if you are using the output with sed or grep.. since the first line would not be identified by - iE - | grep ^172.

By my mean the problem ist:
in the functions header_host_small and header_vm_small, puts @table.header_str returns a newline in the end.
after them scr_restore echoes [[0m and no newline is used.
So if table.header_str could return without newline, or you could to cut this newline an put a new after src_restore .. the output would see like this:
[[1m[[4mNAME^[[0m $
172.22.0.2 $
172.22.0.4 $
172.22.0.5 $
172.22.0.7 $
172.22.0.8 $
172.22.0.9 $

Clean, not??

Best Regards
Marlon Nerling

Associated revisions

Revision 196e7816
Added by Javi Fontan almost 10 years ago

Fixing #99 in trunk

git-svn-id: http://svn.opennebula.org/one/trunk@475 3034c82b-c49b-4eb3-8279-a7acafdc01c0

Revision 83c7c359
Added by Javi Fontan almost 10 years ago

Fixing #99 in 1.2 branch

git-svn-id: http://svn.opennebula.org/one/branches/one-1.2@476 3034c82b-c49b-4eb3-8279-a7acafdc01c0

Revision 107daf14
Added by Guillaume Oberlé almost 3 years ago

Remove orders attributes when removing boot orders (#99)

This is to make sure that the ORDER attribute is removed correctly for disks and nics if we remove OS = [ BOOT = "disk0,...." ] from the XML template of the VM.

History

#1 Updated by Javi Fontan almost 10 years ago

  • Status changed from New to Assigned
  • Priority changed from High to Normal

A fix for this misbehavior is commited to both trunk and 1.2 branch. Check it really fixes the problem described. Thank you.

#2 Updated by Javi Fontan almost 10 years ago

  • Target version changed from Release 1.2 to Release 1.2.1

#3 Updated by Javi Fontan almost 10 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

Also available in: Atom PDF