[Toybox] [PATCH] ps/top: auto-size the PID/PPID fields.

[enh]

an alternative would be to measure the column to fit the *data* like
ls does. i did wonder if that's what GNU ps does, but no, it's using
pid_max and always using a column that wide:

~$ ps
   PID TTY          TIME CMD
  4636 pts/13   00:00:00 bash
  4681 pts/13   00:00:00 ps
~$ ps -A | tail
256286 pts/4    00:00:02 bash
257026 ?        00:00:45 rtkit-daemon
257113 ?        00:05:09 irqbalance
257207 ?        00:04:33 goog_le2
257476 ?        00:00:00 paxctld
258563 ?        00:00:00 uptimed
259644 ?        00:00:08 auditd
259646 ?        00:00:14 audispd
260058 ?        00:24:36 NetworkManager
260864 ?        00:08:37 dnsmasq
~$

all the alternatives seem better than busybox, though, which just
mashes columns together.

if we did do sizing based on content, that would let us fix the TODO
for the selinux LABEL field. (not that i'm aware of anyone having
noticed the hard-coded width there.)

On Sun, Feb 23, 2020 at 12:24 PM enh <enh at google.com> wrote:
>
> On Sun, Feb 23, 2020 at 12:40 AM Rob Landley <rob at landley.net> wrote:
> >
> > On 2/23/20 12:30 AM, enh wrote:
> > > On Sat, Feb 22, 2020, 20:01 Rob Landley <rob at landley.net
> > > <mailto:rob at landley.net>> wrote:
> > >
> > >     On 2/22/20 5:16 PM, enh via Toybox wrote:
> > >     > While most Android devices still have low pid_max values,
> > >
> > >     as does devuan (32768)
> > >
> > >     > my laptop and
> > >     > desktop are using ever higher values. Auto-size the PID and PPID fields
> > >     > based on the system's current configuration rather than hard-coding
> > >     > values.
> > >
> > >     Ew.
> > >
> > >     Out of curiosity, what is your pid_max current set to?
> > >
> > > My laptop's at 256Ki.
> >
> > Can we just bump it up by one for now and wait for it to break again? (That
> > gives us almost two more doublings; if the second ~doubling is "999999" we're
> > still good...)
> >
> > The magic value plus probe seems... inelegant.
>
> i actually thought this was *more* elegant because it works for those
> people already living in the future with 1024Ki or whatever, but also
> doesn't punish folks on small systems by wasting columns in top(1)
> output for pids they'll never achieve. (which is a happier outcome
> than with the mem/swap displays in top where you and i can't agree
> because while showing every last KiB might make sense for very small
> systems, it's unreadable for large systems; but if you make it
> readable for large systems, you lose the detail for small systems
> [706628b94e65cfa9e583d7a54d7cdd8de9f70c63].)
>
> if it's specifically the magic 0 you don't like, pid and ppid are
> adjacent and the first two entries in the table, so slot <= ppid would
> also work. (having a value in the table that we ignore seemed worse to
> me though. 0 is clearly magic, and even sounds like "you work it out
> for me".)
>
> but, yes, s/5/6/ would be good enough to get the columns to line up
> for me again.
>
> > Rob