Look at the left column header and values - they are trimmed by a character. Look at the right hand column values - the "logout" value is truncated. unconnected$ help Comman Description -------------------------------------------------------------------------------- exec Execute a statement or a script help Help on the client and its commands login Log into a server with specified username and password logout Logout and disconnect from the server but does not exit the CLI interpr quit Exit the CLI interpreter record Records user input commands to a specified file versio Show version information and properties 7 rows
increasing priority to major - this affects more than help. I did a "findResources" and the same thing happend - and its cutting off the ID column so if I did this so I can find out the ID of some resource, I couldn't use this mechanism to find it since the full ID isn't shown: rhqadmin@localhost:7080$ findResources('mazzthink') id name versio resourceType -------------------------------------------------------------------------------- 100 mazzthink File System (local) C:\ File System 100 mazzthink Win32 Windows 100 mazzthink Jopr Server, JBossAS 4.2.3.GA default 4.2.3. JBossAS Server 100 mazzthink Embedded JBossWeb Server 2.0.1.GA (0 2.0.1. Embedded Tomcat S 4 rows
https://jira.jboss.org/jira/browse/JOPR-396 is another example of this.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2314 This bug is duplicated by RHQ-2362
I have reviewed the code that determines the column widths, and the problem actually is not specific to the first column. When something is printed in the terminal in the CLI, the following steps are performed: * Iterate through each column of data, row by row, to determine the column widths * Calculate the total width for all of the columns * If the total column width is greater than the available width, divide the available width by the total column width to determine a shrinkage factor * Then reduce each column width by that shrinkage factor. I can illustrate the problem with an example. availableWidth = 100 // available width in the terminal colOneWidth = 10 // required width for text in col 1 colTwoWidth = 150 // required width for text in col 2 totalColWidth = 160 // sum of col 1 width and col 2 width shrink = availableWidth / totalColWidth = 0.625 Now the column widths are adjusted by the shrink number colOneWidth = 10 * 0.625 = 6.25 colTwoWidth = 150 * 0.625 = 93.75 This results in text in both columns getting truncated. I think the problem stems from initially allocating only the necessary width for each column but then uniformly reducing the width of all columns. This results in truncating when we do not have to. Alternatively, I think we should start by evenly distributing the available width across all columns. And then for any column that needs less space than what has been allocated to it, the column width can be reduced and the left over space can be spread across remaining columns. This can be repeated for each column that needs less space than what has been allocated to it. Using the example from above, we can see that this will result in only the second column getting truncated. availableWidth = 100 initialColOneWidth = 50 initialColTwoWidth = 50 requiredColOneWidth = 10 requiredColTwoWidth = 150 actualColOneWidth = 10 actualColTwoWidth = 90 // 50 + the 40 left over from col 1 With this algorithm, column 2 is slightly more narrow than it was in the initial example, but column 1 is no longer is no longer truncated.
A fix for this as described in comment 4 has been pushed and merged into master. Moving to ON_QA.
QA Verified.... I have tried a couple different queries in the CLI, and it no longer appears to get cut off inappropriately.
Mass-closure of verified bugs against JON.