ps enhencements (posix syntax, and more)

[Cyrille Lefevre]

repost to -standard due to rbl,

not CC'ed Garance A Drosihn <drosih at rpi.edu>;
Albert Cahalan <albert at users.sourceforge.net>

"Albert Cahalan" <albert at users.sourceforge.net> wrote:

PS : Albert, do you have another email address, since sf.net reject
all my email bcoz my ISP is often RBL blacklisted :(

> On Wed, 2004-04-21 at 18:54, Cyrille Lefevre wrote:
> > "Albert Cahalan" <albert at users.sourceforge.net> wrote:
> > > On Tue, 2004-04-20 at 13:58, Garance A Drosihn wrote:
> > > > At 10:21 AM +0200 4/20/04, Cyrille Lefevre wrote:
> > > > >I've finished to cleanup my code and to merge recent changes
> > > > >made by Garance. I've get rid of my -X feature for now, and
> > > > >replaced it with -q (posix mode) and -Q (sunos/tru64 compat
> > > > >mode, aka the return of -g which means -a w/o process group
> > > > >leaders, and sizes displayed in KGM format).
> > >
> > > Having a "-q" for posix mode is kind of pointless, no?
> > > The same goes for "-Q".
> >
> > -X has been recently taken.
> >
> > free letters, are : BDEFIJKQRVWYbukq, well K and k are reserved
> > for future use... so, why now -qQ ? do you have any better suggestion ?
>
> No, the point was that adding **any** option to switch
> parser modes kind of defeats the whole idea of trying
> to be compatible with anything.

as suggested by Garrett Wollman, I will change -qQ to -W something,
as done before through -X posix,etc. which have been retired from
the current version.

> You can switch via $PATH and/or some other environment variable.

currently, mode switch is also done through the basename (posix if
the basename contains x, and extended if the basename begins w/
an s) and using an environment variable (see another email about that).
but, some others dislike environment variables...

> > > I re-align columns as I can. If VSZ overflows while
> > > there is some room in the TTY column, the spaces get
> > > grabbed up in order to keep other columns aligned.
> > > This works well.
> >
> > the tru64 alternative is not so bad, you know that the size
> > will not be greater than 7 chars (999.95M). for instance,
>
> This is painful for scripts parsing ps output.

so, the feature to switch between normal and extended mode
is good :)

when -W something will be reimplemented, I will change extended
to sunos and/or tru64 as done originally. so, you'll be able to use
-g without tru64 size display. IMHO, "sunos" compat mode would
have to be the default bsd mode as most of older bsd does.

> > the fixed size is, 5, which is too less  IMHO, but 6 or 7 will
> > be to much. however, this suffice in 95% of cases.
> > under BSD, there is no room in tty !
>
> You usually have room in STAT or TIME.

if time dynamic sizing is implemented. but for instance, it isn't.
stats as not so much room in it (currently, 1 chars at most)

> > > > (-K)    don't show kernel thread (option taken from openbsd -k,
> > > >         *not implemented yet*).

forget what I said here, I'm totally wrong (see another post about that)
OpenBSd -k is FreeBSD -H. sorry for the mistake.

> > > > -g pgidlist    select processes by process group id(s).
> > >
> > > If the PGID list contains non-numeric entries, then you
> > > should parse it as a list of effective group names and IDs.
> >
> > s/should/could/
> >
> > as a general rule, I tend to follow what other "standard" systems
> > does. by "standard", I mean, *bsd, susv3, hpux, irix, solaris and tru64.
>
> OK, don't admit that Linux has become the standard now.

not yet ;P

GNU/Linux systems tries to follow what other systems do, but often do it
differently.
let's try ifconfig -a, etc. the output is really different from most systems,
but it's OOT.

> (You're dying, remember?) Also, you forgot AIX and DYNIX/pts.

don't have AIX nor DYNIX/pts for testing.

> Just look at how neatly -g matches up with -U, -u, and -G.
> Not that I entirely made this up though: I remember once
> finding an OS that only used -g for effective groups.
>
> > this also works pretty well and does not need  C code editing :)
> >
> >          * internal format syntax:
> >          *      keyword[:flags in reverse polish notation][=header]
> >          * reverse polish notation:
> >          *      x by itself, * means any, x! means not x,
> >          *      xy| means x | y, xy& means x & y, xy^ means x ^ y.
> >          *      [xyz] is a more compact and readable form of xy|z|
> >          *      [a-z] isn't supported and is understood as a-|z|
> >          *      () may be used for readability but are no-op.
> >          * bsd flags: d12jlsuv, bsd modifiers: nZ
> >          * posix flags: d12fjl, posix modifiers: cMPy
> >          * both modifiers: X if extended.
> >
> >         static char bsd_fmtstr[] = "\
> > label:Z user:[ju](n!)& uid:([ju]n&)([ls]([ju]!)&)| pid:2! ppid:[jl] \
> > pgid:j sid:jX& tpgid:jX& tsid:jX& jobc:j sig:s sigmask:s sigignore:s \
> > sigcatch:s cpu:l pri:l nice:l %cpu:u %mem:u vsz:[lu] rss:[lu] \
> > mwchan:l(n!)& nwchan:ln& tt:[d2u](vX&)| state:1! tt:[jls]([du]!)& \
> > start:u time:1! sl:v re:v pagein:v vsz:v([lu]!)& rss:v([lu]!)& lim:v \
> > tsiz:v %cpu:v(u!)& %mem:v(u!)& command:1! \
> > ";
>
> I am reminded of sendmail. You're getting close.

maybe, but this kept the code as small as possible. encode this using
if else if etc. and the code will be at least twice the actual one.

> > > will make transition to a mixed POSIX/BSD parser much
> > > more difficult, because you won't be able to fall back
> > > to a pure BSD parser when "ps -ax" is seen.
> >
> > in the actual code, the syntax aren't mixed at all.  so, no
> > transition is needed (except if options aren't preceded
> > by a dash which means goes in bsd syntax). the syntax
> > selection is based on the program name, and eventually,
> > on an environment variable, if compiled in,
>
> As a primary mechanism, this makes sense. What about when
> you hit an error? You could add/remove the "-" and re-exec
> (once at most!) to get a second chance at doing what the
> user wanted.
>
> > > > size    alias to sz [just for convenience]
> > >
> > > Nope. This is the size of your swappable image.
> > > That would be dirty pages in RAM plus pages in
> > > swap, plus anything else (page tables?) that you
> > > could swap out. Origins may involve Novell or SCO.
> >
> > well, yes, originally implemented as :
> >
> > void
> > size(KINFO *k, VARENT *ve)
> > {
> >         VAR *v;
> >
> >         v = ve->var;
> >         (void)printsize(wlufmt, v->width,
> >                     ps_pgtok((u_long)k->ki_p->ki_dsize) +
> >                     ps_pgtok((u_long)k->ki_p->ki_ssize));
> > }
> >
> > but, here also,  there is no consescus between all flavor
> > of unices. hpux and irix says it's dsize+ssize+tsize, sunos
> > says (as I remember me) it's dsize+ssize, tru64 says sz
> > is rss, while solaris says it's osz (aka vsz in pages).
> > since the dsiz and ssiz keywords where added, I prefered
> > to say that sz (alias size) is an alias to vsz since rss is also
> > displayed w/ -y.
>
> This all makes sense for: sz, vsz, osz, rss
> BTW, you forgot Tru64 rssize. It's rss with an RSS header.

right, as currently implemented :)

> If you don't implement "size" as being the amount of
> stuff that could end up in swap, then there isn't any
> format specifier that covers that.

any other opinion ?

> The POSIX spec has a strange distinction between SZ and vsz.
> Observe:
[snip]
> Damn that spec is vile.

well, that's not help.

Cyrille Lefevre.
-- 
home: mailto:cyrille.lefevre at laposte.net