|open canot handle lines longer as 79 characters

[Cecil Westerhof]

I have the following statement:
set topOutput [open "|top -bc -d 5 -n 2"]

But when this command gives a line that is longer as 79 characters, it
replaces the line with the first 78 characters with a + appended to
it. Is this normal behaviour? And if so: how can I retrieve the
complete line?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> I have the following statement:
> set topOutput [open "|top -bc -d 5 -n 2"]
>
> But when this command gives a line that is longer as 79 characters,
> it replaces the line with the first 78 characters with a + appended
> to it. Is this normal behaviour? And if so: how can I retrieve the
> complete line?

Top is a curses/ncurses based tool. That is likely top believing
(incorrectly) that it is running on a terminal with an 80 character
line width, and itself truncating the output for you. Or, it is
possible that when top detects no terminal, it simply formats for 80
characters wide by default.

[Brad Lanam]

On Wednesday, January 3, 2018 at 3:39:09 PM UTC-8, Rich wrote:

And top, being curses based, is probably also outputting all sorts of terminal
escape sequences.

You would be better off using 'ps'. Modern 'ps' programs have a lot of
options to display the information you want.

[Cecil Westerhof]

That was the problem. I added '-w 132' and I get the information I
need.

Thanks.


But I got a new problem.
When executing:
while {-1 != [gets ${topOutput} line]} {
if {[lindex ${line} 0] == "PID"} {

I get:
unmatched open brace in list
while executing
"lindex ${line} 0"

When line contains a "{". Which is possible.

I solved this with:
while {-1 != [gets ${topOutput} line]} {
set line [string map { "{" "" "}" "" } ${line}]
if {[lindex ${line} 0] == "PID"} {

Is this the correct way, or is there a better way?

[Cecil Westerhof]

The problem is that ps displays information about the complete runtime
of the programs (just as the first iteration of top, that is why I use
-n2) while I am interested in the current CPU usage.

[Rich]

No, not correct. You are passing a string (gets returns strings) to a
list operator. Never apply list operators (lindex) to string values.

Convert your string into a proper list first. If you want non white
space tokens separated by runs of whitespace, then this works well:

regexp -all -inline {\S+} <your string here>

I.e.:

$ rlwrap tclsh
% set x "a b { c d"
a b { c d
% lindex $x 1

unmatched open brace in list

% set y [regexp -all -inline {\S+} $x]
a b \{ c d
% lindex $y 1
b

If you know you have only single character separators, then 'split'
works great for those.

[Cecil Westerhof]

I thought that in tcl everything was a string. ;-)

> Convert your string into a proper list first. If you want non white
> space tokens separated by runs of whitespace, then this works well:
>
> regexp -all -inline {\S+} <your string here>

It did work, but I changed it to the better:
while {-1 != [gets ${topOutput} lineStr]} {
set lineLst [regexp -all -inline {\S+} ${lineStr}]
if {[lindex ${lineLst} 0] == "PID"} {

[Arjen Markus]

On Thursday, January 4, 2018 at 6:44:06 AM UTC+1, Cecil Westerhof wrote:

>
> I thought that in tcl everything was a string. ;-)
>

That is true, but you were using an arbitrary string as a list and the reverse is not true. A list is automatically converted into a string, but not all strings are a valid representation of a list. One simple example: "A{B}" - the braces get in the way.

Regards,

Arjen

[Rich]

Yes. But not every string is a list.

You encountered one of those spots where a string was not a list.