Description of problem: clustat(8) offers no way of obtaining untruncated columns when its stdout is not a TTY. As a result, it is impossible to obtain untruncated service names when calling clustat(8) from a script or any situation where its output is being parsed programmatically. Version-Release number of selected component (if applicable): Latest available in RHEL5. The cluster3 master branch at: http://sources.redhat.com/cluster/wiki/ also exhibits this behavior. How reproducible: Always. From rgmanager/src/utils/clustat.c: 34 int dimx = 80, dimy = 24, stdout_is_tty = 0; [...] 1103 if (isatty(STDOUT_FILENO)) { 1104 stdout_is_tty = 1; 1105 setupterm((char *) 0, STDOUT_FILENO, (int *) 0); 1106 dimx = tigetnum("cols"); 1107 dimy = tigetnum("lines"); 1108 } dimx is initialized to 80 columns. No code other than the above modifies dimx. Therefore, when the environment variable COLUMNS is set, its value is never honored when stdout is not going to a TTY. This causes the Service Name column to be truncated as though the output was being emitted on an 80-column terminal: Service Name Owner (Last) State ------- ---- ----- ------ ----- service:cl01-svc01.roch.ny.exa (cl01-host01) disabled service:cl01-svc02.roch.ny.exa (cl01-host02) disabled service:cl01-svc03.roch.ny.exa cl01-host03 started service:cl01-svc04.roch.ny.exa cl01-host04 started Ideally, columnar data would *never* be truncated when output is not going to a TTY, so programmatic callers do not have to worry about setting COLUMNS.
Use clustat -l or clustat -x
Lon, any chance you'll re-consider... it seems you offered workarounds but it would be nice to fix this so that output isn't truncated. I don't see how that behavior is desirable or a 'feature'... but perhaps you can enlighten?
(In reply to comment #1) > Use clustat -l or clustat -x both outputs are nontrivially more complex to parse than the default output. if the output is not a TTY then why ought clustat(8) assume to wield any jurisdiction over the column count of the output? by nature, it has NO IDEA where the data is going, so it should not make any assertions. it's clearly not a bug because the program is working precisely as designed. thus, it is a design flaw. if this behaviour is something that there is reason to believe other applications are already depending on (eg, the malformed/truncated output in the default output mode), it is not beyond reason to add a flag that allows the default output to do the right thing it ought to be doing already