zsh-users
 help / color / mirror / code / Atom feed
From: Dominik Vogt <dominik.vogt@gmx.de>
To: zsh-users@sunsite.auc.dk
Subject: Re: displaying top cpu using process
Date: Sun, 8 Apr 2001 14:49:46 +0200	[thread overview]
Message-ID: <20010408144946.A640@gmx.de> (raw)
In-Reply-To: <1010407182602.ZM15804@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Sat, Apr 07, 2001 at 06:26:01PM +0000

On Sat, Apr 07, 2001 at 06:26:01PM +0000, Bart Schaefer wrote:
> On Apr 7,  4:33pm, Dominik Vogt wrote:
> } Subject: displaying top cpu using process
> }
> }   ps gives me complete control over the output format, but I can't
> }   make it give me the CPU percentage.  Although the 'C' output
> }   modifier is documented as 
> } 
> }     "use raw CPU time for %CPU instead of decaying average"
> } 
> }   I always get the decaying average.
> 
> I can't even get my "ps" to accept the C modifier.  It keeps interpreting
> it as the "selection by command name" option, and telling me that only
> root is allowed to do that.

I remember that it was very difficult to make ps accept its
options, but it is possible.  The man page is really crap.  I
don't have the line handy right now, but I can look it up on
monday.

> }     top -b -n 1 | sed '<script>'
> } 
> }   But then, this only works if the terminal window from which top
> }   was started has enough lines. [...]  To get the full output I
> }   have to detach top from the terminal.  
> 
> That's odd; on RH6.2, for me, "top -b -n 1" produces a lot more lines
> of output than the height of the terminal.

Yes, it produces full output as long as the terminal window has at
least eight lines.  If the window is smaller, top only writes the
headers but no process information.

> (procps-2.0.6-5)  However,
> try fooling it by stuffing the LINES and COLUMNS environment variables.

Yes, that's it.  Setting LINES to a big value makes top produce
full output.  Now, how can I protect LINES from being reset when
the window is resized?

> }   In other words, I need one process that generates the data and one
> }   that writes it into the terminal window. There are several ways to
> }   do this, but the best solution seems to be a coprocess (because the
> }   coprocess is killed if the terminal window that runs the script is
> }   closed).
> 
> A coprocess is overkill.  Just use the parameter assignment and a pipe:

Yes, with a way to make top produce output in a 20x1 window a
background process is not necessary.

> topcpu {
>   local p=0 pid user pri ni size rss share stat lib cpu mem time command
>   LINES=10 COLUMNS=200 top d 2 c b n 43200 |
>   while read pid user pri ni size rss share stat lib cpu mem time command
>   do
>     [[ $pid == PID ]] && { p=1; continue }
>     (( p )) && { print $pid $cpu% $command; p=0 }
>   done
> }

Unfortunately the read command above will not work reliably which
complicates things a lot.  The number of space separated words in
the top output varies:

  354 luthien    8   0  2000 2000  1376 S     0.0  1.5   0:00 zsh
  525 luthien   13   5  1148 1148   932 S N   0.0  0.9   0:00 startx
                                        ^^^

> 43200 iterations of 2 sec is 24 hours.


My solution looks like this:

---------------------------------------------------------------
#!/usr/bin/zsh

emulate zsh
setopt EXTENDED_GLOB

function topcpu ()
{
  local p=0 pid rest
  LINES=10 COLUMNS=200 top -d 2 -c -b -s -n 1 |
  while read pid rest; do
    [[ $pid == PID ]] && { p=1; continue }
    (( p )) && {
      if [ ! $rest[57,60] = "top " ]; then
        print -n "\n"$pid ${rest[44,48]## ##}% ${rest[57,99]}
      fi
      return
    }
  done
}

topcpu
if [ -n $1 ]; then
  while true; do
    sleep $1 2> /dev/null
    topcpu
  done
fi
---------------------------------------------------------------

To circumvent the problem of the window being resized, the
function is called in a loop with a single pass of top each.
I call it from xterm:

  xterm -g 20x1 -font 5x7 +sb +aw +ah -e topproc 15

Unfortunately I can't make the cursor the same colour as the
window background.  Although xterm allows to set the colour, it
ignores the setting if it's identical to the background colour.
I guess I'll have to live with that (it *is* possible to solve,
even with the themes setup in fvwm, but it's not worth the
effort).

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de


  reply	other threads:[~2001-04-08 12:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-07 14:33 Dominik Vogt
2001-04-07 18:26 ` Bart Schaefer
2001-04-08 12:49   ` Dominik Vogt [this message]
2001-04-08 17:04     ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010408144946.A640@gmx.de \
    --to=dominik.vogt@gmx.de \
    --cc=zsh-users@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).