[Toybox] ps is cheating.

[Rob Landley]

On 10/17/2015 01:38 PM, enh wrote:
> fwiw, android has never cared much about the 80 column limit. we'll
> show up to 1024 characters of /proc/pid/cmdline:
> 
> USER      PID   PPID  VSIZE  RSS   WCHAN              PC  NAME
> enh       18223 4219  902252 142880 futex_wait 7f67f08177ce S
> /opt/google/chrome/chrome

I'm fetching 2048 chars (half of toybuf) but only displaying that if
it's the last column and the truncate to screen width option is disabled
with -w (which isn't implemented yet but I'm probably just having _one_
-w for unlimited rather than this -ww repeating nonsense from procps).

> our PC column was truncated on LP64 for a long time before anyone noticed.

Ok, you've got "pc" for what I'm calling "addr". Hmmm. (I can certainly
add it as an alias. And I _am_ truncating... to 12 chars. Although I've
already implemented the "explicit width control" logic from the man page
ala "ps -o pc:16" (and yes, you can use = and : on the same entry
although : has to go first).

While I do want to grab the column auto-adjust logic from vmstat.c
(which is _not_ the same auto-adjust logic as ls -l, in vmstat it steals
unused spaces from adjacent columns, in ls it precomputes all the
columns to measure them), neither really quite matches the ability to
explicitly specify column sizes.

I'm vaguely planning to grab the vmstat approach (_after_ otherwise
finishing and promoting this sucker), treating the specified sizes as
"pad out to", and then letting _only_ the numeric fields (and maybe
wchan) expand because usernames and cmdline can be pathologically long
if you don't truncate them.

The rightmost column already expands out to screen size (or to unlimited
with -w... why don't I implement -w now while I'm thinking about it...).

And come to think of it, the default shouldn't be 80. If you haven't got
a tty, behave like -w (INT_MAX).

> our default columns are unusual too (the above output is the default).
> (PC is the kernel's "kstkeip".)

Um, do you mean entry #29 "EIP" from /proc/$PID/stat?

I see you're also printing it in hex. All the other fields are decimal
(except the one that's specified as _octal_ by posix), but decimal is
just too many digits here (and not what anybody's going to be comparing
/proc/$PID/maps and objdump -d output against if they really need to
dissect a running process without gdb. And yes, I have done that.

> we also had numeric wchan output for years and no-one complained. in
> fact, it wasn't until i got a patch to increase the width for the
> numeric output for LP64 (!) that it annoyed me enough to fix it.

I'm already reading the proc/$PID/wchan data for that field. I was
considering having addr be the numeric wchan (posix doesn't _say_) but
it's zero a lot and EIP should never be, so... more useful.

Rob

 1445116233.0