[Toybox] ps down, top to go

[enh]

On Mon, May 9, 2016 at 4:47 PM, Rob Landley <rob at landley.net> wrote:
>
>
> 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.

compare

./toybox ps -A -T -o pid,tid,comm,command

with

ps -A -T -o pid,tid,comm,command

>>> 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.

(remember i only care about this for batch mode, for inclusion in a
bug report. so columns are basically unlimited. i think it's
reasonable to argue that using top -O and expecting to fit in 80
columns is clearly unreasonable, and you should use -o to choose for
yourself how to divide up the space.)

> 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.

many long options just aren't worth a short option. there are 26*2
available short options, and everyone's better off if they're at least
somewhat mnemonic but the most important thing is that you can type
them quickly because you use them all the time. whereas for
rarely-used long options it's better if you don't waste a precious
short option, and you're more likely to remember the descriptive
option. (long options work really well for --something/--no-something
pairs too.)

>>> (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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.