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 <[email protected]> wrote: > > On Sun, Feb 23, 2020 at 12:40 AM Rob Landley <[email protected]> wrote: > > > > On 2/23/20 12:30 AM, enh wrote: > > > On Sat, Feb 22, 2020, 20:01 Rob Landley <[email protected] > > > <mailto:[email protected]>> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
