[Toybox] ps down, top to go

[Rob Landley]

On 05/06/2016 11:49 PM, enh wrote:
> On Fri, May 6, 2016 at 9:11 PM, Rob Landley <rob at landley.net> wrote:
>> On 05/06/2016 08:34 PM, enh wrote:
>>> On Fri, May 6, 2016 at 6:01 PM, Rob Landley <rob at landley.net> wrote:
>>>>>  1794  1806 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_1
>>>>>  com.android.onetimeinitializer
>>>>>  1794  1807 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_2
>>>>>  com.android.onetimeinitializer
>>>>>  1811  1811 u0_a24   20   0   0% S 1518092K  57752K  bg
>>>>> ndroid.calendar com.android.calendar
>>>>>  1811  1816 u0_a24   29   9   0% S 1518092K  57752K  bg Jit thread
>>>>> pool com.android.calendar
>>>>
>>>> Wordwrapping in the original?
>>>
>>> yeah, sorry. gmail hates long lines.
>>
>> Makes it hard to see what you're going for, but I _think_ I understand.
>> Your fields are padded to fixed starting points and "thread name" is
>> whitespaced out if this isn't a thread?
> 
> well, i can use field:123 to deal with that, plus thread names are
> limited to 12 characters or so by the kernel anyway...
> 
> my real problem is that i don't currently have a field that gives me
> the process name in -T/-H mode.

Define "process name"?

There are 6 right now: args, cmd, cmdline, comm, command, and name.

COMM is stat[2], NAME is argv[0] minus the path, COMMAND is argv[0] with
the path.

Those are the three variants of "process name", the rest show command
line arguments too: CMDLINE is the full unmodified command line. ARGS is
the full command line using NAME for argv[0] (I.E. minus the path to the
binary you're running, if any). And then CMD is this crazy posix thing
that's one of the others depending on your command line options.

>> Oh _I_ can win in that what I, personally, want is to look up the names
>> as a group. Whether it's what everybody else wants, I couldn't tell you. :)
>>
>> (Did you know "top -O" in ubuntu lists all the available field names? I
> 
> i only found that out while experimenting recently. i'd assumed it
> worked like ps' much more useful -O.

The problem is ps's default output has buckets of free space and top's
doesn't, so if -O inserts fields it pushes stuff off the right edge
pretty quickly.

On the other hand what we COULD do is have top -O insert fields into the
_ps_ default output fields. So "pid,tty,time,%s,cmd" with the sort
starting on field 4 (the first supplied -O field)...

Or, -O could replace "pr,ni,virt,res,shr,s" in top... Hmmm, that might
thingy...

>>>> (Of course when I sat down to clean up the ps help text, the first issue
>>>> is that I implemented a lot more fields for top and pgrep and such than
>>>> ps --help currently lists, and when trying to document them all I went
>>>> down the rathole of trying to figure out what the difference between -o
>>>> PR and -o PRI actually is, which involved reading kernel source for an
>>>> hour (the comment on task_prio() in kernel/sched/core.c does not seem to
>>>> match the MAX_RT_PRIO value from include/linux/sched/prio.h), and then I
>>>> got interrupted, and I have a half-finished blog entry about it and it's
>>>> on the todo list. The REALLY sad part is I worked through this and
>>>> understood it when I implemented it, but didn't write it _down_. You'd
>>>> think I'd know better by now...)
>>>
>>> these kinds of things are, i think, the best argument for a logical
>>> grouping. makes it easier to contrast them with one another. but the
>>> ps help is already pretty long.
>>
>> Tell me about it. That gets us back to "top -O", except "ps -O" already
>> means something else and I'd want it consistent so pick another letter...
> 
> even though you hate them, this is one of the nice things about long
> options. they're easier to remember, and no one cares that you've
> already taken --list-fields because they're not likely to want
> --list-fields to mean anything else.

I just like there to be a short option corresponding to each long option.

>> (And I gotta finish ioctl...)
> 
> that seems too broken for me to believe anyone's actually been using
> it. but then one might equally well say that about the kernel's ioctl
> interface and it's sadly not dead yet.

I did half a replacement once and I should finish it. Alas, there's a
dozen things I could say that about and the past few days I've been
wrestling with j-core repository conversion.

(And if there's going to be a "sysctl" command, there might as well be
an ioctl command...)

Sigh, I had this message half-finished for a few days and looking back
I'm going "Oh right, I forgot I was in the middle of that" about 3
different things. I suspect I should pull up the mailing list threads
for the month to re-read on the plane...

Rob