in reply to Re^2: unexplained output from top in batch mode
in thread unexplained output from top in batch mode

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+/

-Paul

Replies are listed 'Best First'.
Re^4: unexplained output from top in batch mode
by zentara (Cardinal) on Jan 13, 2007 at 14:13 UTC
    Thanks for looking at it, but now I think it is something weird with Claws output. When I look at the entry for the pid in /proc, the name is different in different places. In /proc/$pid/cmdline, it is correctly shown as 'claws'. But in /proc/$pid/status, it shows it's Name as 3. So I think it is a problem with Sylpheed-Claw's way of reporting iteslf? Every other process seems to have Name and cmdline as the same (or similar).

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      Hrm, my leading spaces comment doesn't really make any sense looking back, but I was just rejecting the idea it had to do with open3. The problem really has to be with the way top is reading the procs or the way you're parsing it.

      Pretty sure you can set cmdline with $0, which is probably what claws is doing (or the C analog or whatever), but I'm really not sure what /status is set from. I seem to recall it comes from something else.

      -Paul

        Yeah, I think they key is that if I dump the output of "top -b" to a file, like "top -b >>top.out", the name 'claws' appears as the command name. But if I send thru the IPC pipe, it turns to '3', which may be the filehandle's fileno? I don't know, but every other app I've tried seems to work Ok, so I posted it as a bug report with sylpheed-claws, so we will see what they say.

        I'm not really a human, but I play one on earth. Cogito ergo sum a bum