On Mon, May 9, 2016 at 5:28 PM, enh <[email protected]> wrote: > On Mon, May 9, 2016 at 4:47 PM, Rob Landley <[email protected]> wrote: >> >> >> On 05/06/2016 11:49 PM, enh wrote: >>> On Fri, May 6, 2016 at 9:11 PM, Rob Landley <[email protected]> wrote: >>>> On 05/06/2016 08:34 PM, enh wrote: >>>>> On Fri, May 6, 2016 at 6:01 PM, Rob Landley <[email protected]> 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
(since it's taken this long and you still don't see what i'm saying, i guess i shouldn't assume you're seeing what i'm seeing... here's what i see for some random chrome processes with ps: 86993 86993 chrome /opt/google/chrome/chrome --type=renderer --lang=e 86993 86997 Chrome_ChildIOT /opt/google/chrome/chrome --type=renderer --lang=e 86993 86999 Compositor /opt/google/chrome/chrome --type=renderer --lang=e 86993 87000 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e 86993 87001 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e 86993 87002 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e 86993 87003 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e 86993 87004 handle-watcher- /opt/google/chrome/chrome --type=renderer --lang=e 86993 87005 HTMLParserThrea /opt/google/chrome/chrome --type=renderer --lang=e 86993 87008 ScriptStreamerT /opt/google/chrome/chrome --type=renderer --lang=e 86993 128020 WorkerPool/5655 /opt/google/chrome/chrome --type=renderer --lang=e and then toybox (ignoring that toybox mangled the large tid for the last thread): 86993 86993 chrome /opt/google/chrome/chrome (deleted) 86993 86997 Chrome_ChildIOT [Chrome_ChildIOT] 86993 86999 Compositor [Compositor] 86993 87000 CompositorTileW [CompositorTileW] 86993 87001 CompositorTileW [CompositorTileW] 86993 87002 CompositorTileW [CompositorTileW] 86993 87003 CompositorTileW [CompositorTileW] 86993 87004 handle-watcher- [handle-watcher-] 86993 87005 HTMLParserThrea [HTMLParserThrea] 86993 87008 ScriptStreamerT [ScriptStreamerT] 86993 12802 WorkerPool/5655 [WorkerPool/5655] ) >>>> 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. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
