UPDATE: Would you mind restating, "'home/zentara/bin/claws' shows up as a name 3 in the output.?" I may not have answered anything relevent in the rest of this post.
I don't think split /s\+/ is going to be very robust here. The columns have a certain width and the fields may have spaces in them... A ways back I had written a funny little toy that I seem to use over and over. Perhaps I should make it into a proper module.
It'd work like so:
use magic_columator;
while(my @row = $col->fetchrow) {
# do stuff
}
This would be a great place to use iterators I think. There are also probably already modules that do this more cleanly. If you were to use it, or something like it, it'd need some major updates and fixes I suspect.
| [reply] [d/l] [select] |
Well, if you use the script in ztk-visual-top-w-kill, and go into the thread where I sysread top's output. and print the $buf,
sysread(READ,$buf,8192);
print "$buf\n\n";
you will see that top's batch output is setting the name to 3 (at least on my machine for /home/zentara/bin/claws), when it's still a string, before any split occurs. So the question is whether it is top's -b option that does this, or does the IPC::Open3 pipe somehow change it? When top is run in normal mode(like in an xterm), the name is shown correctly. Also if I do "top -b >>top.output", the name is shown correctly as "claws". So somehow, coming thru the IPC::OPen3 pipe is causing it to change. Is it possible that a pipe is interpreted to be a weird terminal type (not vt100)?
| [reply] [d/l] |
K, then I stand by my previous guess. Sometimes columns can have embedded spaces (like the leading spaces on RES and SHR, etc), and I think that might be messing up your column numbers. If it's just the one process getting renamed, I'd look for something stranger going on, but somehow I think it's going to relate to split /\s+/
| [reply] [d/l] |