Julian Elischer <[EMAIL PROTECTED]> writes:
> we need to extend this to handle a full thread table per process..
> anyone have any ideas on how to do this?
Unfortunately, I think we're going to end up reimplementing procfs in
the sysctl tree...
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To
Cyrille Lefevre wrote:
> On Tue, Jun 11, 2002 at 05:15:17AM -0700, Juli Mallett wrote:
...
> > would like to see done to ps(1) :) The most notable request was for a
> > feature I've missed having in our ps(1) for a while, the ability to get a
> > tree of processes printed so you can tell who is
On Tue, Jun 11, 2002 at 05:15:17AM -0700, Juli Mallett wrote:
> Hej,
>
> As some of you may have noticed, I've done some poking of ps(1) lately, and
> this has brought attention of people who have ideas for things that they
> would like to see done to ps(1) :) The most notable request was for a
we need to extend this to handle a full thread table per process..
anyone have any ideas on how to do this? Anyone rewriting ps should think
about this twist...
On 11 Jun 2002, Dag-Erling Smorgrav wrote:
> Juli Mallett <[EMAIL PROTECTED]> writes:
> > I believe I can get pid, ppid, username (or
Juli Mallett wrote:
> > Piping commands through other commands seems icky?
>
> Relying on reasonable output from ps(1) seems icky when you can extract the
> data yourself and not have to worry about formatting getting in the way of
> processing data properly.
This is just wrong on so many levels
Juli Mallett wrote:
> > |-omniNames---omniNames---3*[omniNames]
>
> That seems frighteningly useless to me though. Seems a bit like a number of
> utilities I've seen from the Linux camp which take useful functionality and
> mask it behind something that looks good. What exactly can you get
On Tue, 11 Jun 2002 07:29:56 MST, Juli Mallett wrote:
> > I don't think you should worry too much about _not_ getting
> > reasonable output from POSIX-conformant utilities. :-)
>
> I'd read SUS's ps(1) escription a little closer. Very few guarantees
> with it.
My POSIX.2 (1993) suggests that
* Sheldon Hearn <[EMAIL PROTECTED]> escriurères
>
>
> On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote:
>
> > > Piping commands through other commands seems icky?
> >
> > Relying on reasonable output from ps(1) seems icky when you can extract the
> > data yourself and not have to worry abo
Juli Mallett <[EMAIL PROTECTED]> writes:
> I believe I can get pid, ppid, username (or at least uid [yay
> user_from_uid]), etc., from sysctl(3) at least as easily as with
> kvm(3).
You can get the full process table from sysctl (kern.proc.all)
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To
On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote:
> > Piping commands through other commands seems icky?
>
> Relying on reasonable output from ps(1) seems icky when you can extract the
> data yourself and not have to worry about formatting getting in the way of
> processing data properly.
* Andrew Kenneth Milton <[EMAIL PROTECTED]> escriurères
> +---[ Juli Mallett ]--
> |
> | Wasn't really aware of that existing, but my understanding from another message
> | in this thread is it just works with the output from ps(1)? That seems a bit
> | icky to me.
>
> Pi
Le 2002-06-11, Juli Mallett écrivait :
> mask it behind something that looks good. What exactly can you get from
> that kind of output?
The overall organization of the tree. Useless if the information you
are looking for is 'what is the PID of the father of X', but may be
useful when you have s
+---[ Juli Mallett ]--
|
| Wasn't really aware of that existing, but my understanding from another message
| in this thread is it just works with the output from ps(1)? That seems a bit
| icky to me.
Piping commands through other commands seems icky?
--
Totally Holistic
* Sheldon Hearn <[EMAIL PROTECTED]> escriurères
> On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote:
> >
> > As some of you may have noticed, I've done some poking of ps(1) lately, and
> > this has brought attention of people who have ideas for things that they
> > would like to see done to ps
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> escriurères
> Juli Mallett <[EMAIL PROTECTED]> writes:
> > ps(1)'s internals, however, didn't seem quite right to me, but after about
> > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive
> > programming to produce an N-level tree
* Thomas Quinot <[EMAIL PROTECTED]> escriurères
> Le 2002-06-11, Juli Mallett écrivait :
>
> > feature I've missed having in our ps(1) for a while, the ability to get a
> > tree of processes printed so you can tell who is whose child, etc.
>
> Yes, this would be an invaluable feature!
>
> Ev
Peter Edwards <[EMAIL PROTECTED]> writes:
> Isn't the kvm_*() interface somewhat frowned upon? Is there anything
> missing from /proc that you need kvm_* for?
/proc is also frowned upon, use sysctl.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote:
>
> As some of you may have noticed, I've done some poking of ps(1) lately, and
> this has brought attention of people who have ideas for things that they
> would like to see done to ps(1) :) The most notable request was for a
> feature I'v
Juli Mallett <[EMAIL PROTECTED]> writes:
> ps(1)'s internals, however, didn't seem quite right to me, but after about
> 10 minutes reading kvm(3) manpages and recalling some tricks with recursive
> programming to produce an N-level tree with as many as N-1 elements, I had
> come up with a simple u
Le 2002-06-11, Juli Mallett écrivait :
> feature I've missed having in our ps(1) for a while, the ability to get a
> tree of processes printed so you can tell who is whose child, etc.
Yes, this would be an invaluable feature!
Even nicer would be a user interface (command line, output style)
c
Solaris has something similar in /usr/proc/bin/ptree. One of the things
it lets you do is specify _which_ user to use.
Isn't the kvm_*() interface somewhat frowned upon? Is there anything
missing from /proc that you need kvm_* for?
--
Cheers,
Peter.
Juli Mallett wrote:
> Hej,
>
> As some of
21 matches
Mail list logo
