ps enhencements (posix syntax, and more)

[Cyrille Lefevre]

"Jilles Tjoelker" <jilles at stack.nl> wrote:
> On Thu, Apr 22, 2004 at 12:54:51AM +0200, Cyrille Lefevre wrote:
> > > > fname   FNAME   alias to ucomm [solaris]
>
> > > Yes, except that it's narrow. Make it 8 characters wide.
>
> > yes, I know, but, for instance, it's just an alias and I don't
> > understand the 8 char limit ? 13 yes, but 8 !
>
> Because solaris does it that way.

good answer :)

> Quoting from the pr:
>
> > -s    show signal output, same as -O SFMT (option taken from tru64
> >       conflicts w/ netbsd -s, aka show threads w/ different fields
> >       IMHO, this may be implemented as part of freebsd -H).
>
> Historic BSD used it to show kernel stack size. Tried with Ultrix
> 4.x, NextSTEP and 4.3BSD-Quasijarus. It may look like (from the latter):
>
[snip]
>
> The 4.3BSD man page says:
>      s    Adds the size SSIZ of the kernel stack of each process
>           (for use by system maintainers) to the basic output
>           format.
>
> It's quite likely that 's' for signals is an OSF invention.

your are right and wrong. I'm using as a reference, 4.3BSD reno which
seems to be the first BSD version to introduce "keywords" before 4.4BSD.
and 4.3BSD code says that -s is SFMT, while anterior versions say what
you say. however, the 4.3BSD reno manual page has not been updated to
match the code :(

> >     added keywords (bsd) :
>
> Keep the -o option equal between bsd and posix modes, if possible.

well, they are. by "added  keywords (bsd)", I mean keywords which comes
from other BSD implementations.

> >    enhancements to the posix syntax are :
> >    -O              same as -o pid,fmtlist,tty,time,comm
>
> Where do you have this from? Keep this -O same as BSD -O if possible.

under BSD, pid, tt, state, time and command are the default fields used by all
formats,
while under POSIX, it's pid, tty, time and comm. not my fault.

> SUSv3 mentions BSD's -O in an informative section and recommends -O
> being used for that purpose.

right and wrong, the sysv3 manual page says :

"In a new BSD version of ps, a -O option can be used to write all of the default
information"

note the "default information".

they also said : "This was not adopted because the default output is
implementation-defined."

so, it's implementation-defined :)

> > Format string which contains both an equal sign and a comma are considered
> > to be comma only separated list. so, both
> > -o "pid=process id,ppid=parent pid,command=command line" and
> > -o "pid=child ppid=parent command=command" are well parsed,
> > unfortunately, mixing "user=user name,pid=pid command" isn't...
>
> Hmm, FreeBSD 5.x follows the spec exactly in this respect, an equal sign
> marks the rest of the argument as header text, so I doubt whether it's
> worth doing this. Note that FreeBSD 4.x aborts header texts at a comma
> or space.

any other opinion ?

> >   findvar() rewritten to handle header specification on aliases.
> >   now, you may say "ps -O acflg=XXX" as well as "ps -O acfalg=XXX"
>
> There's a PR of mine open on that, too (much simpler).

your implementation isn't recursive, so -o RUSAGE could'nt be handled.

> > -t '?' to select process not attached to a terminal (from older bsd)
>
> Good.

-t - has just been implemented, also (from netbsd and probably some older bsd).

both options are now handled at kernel level.

> > tsid added in -j format string
>
> Use sid instead, it's more informative (in case of processes that can't
> access their ctty anymore (like 'p2-') or don't have a ctty at all). I
> think I had a PR for that, too (certainly a local patch, at least).

you are right, I forgot to say that sid as also been added, as well as
tpgid and tsid, but only if -Q (or -W extended in the future) is given.
maybe sid should be added to the default format string (w/o -Q) ?

# bps -jQ
USER   PID  PPID  PGID   SID TPGID  TSID JOBC STAT TT       TIME COMMAND

> > if (!S_ISCHR(sb.st_mode)) {
>
> Use isatty(3) for checking whether it's a tty. Things like ps -t
> /dev/da0s1a are meaningless but I think your patch will not reject it.

isatty(3) needs a file descriptor. do you intend that each -t args with an
absolute path would have to be opened, checked w/ isatty(2), then close ?
why not, any other opinion ?

thanks for you review.

Cyrille Lefevre.
-- 
mailto:clefevre-lists at 9online.fr