[Toybox] [PATCH] ps: widen the VSIZE field for Android's default view.

[enh]

On Tue, Feb 28, 2023 at 8:10 AM Rob Landley <rob at landley.net> wrote:
>
> On 2/27/23 12:05, enh wrote:
> >> Sigh. I dunno, one possibility is to redefine -O work off a "PID,TTY,$STUFF,CMD"
> >> base regardless of context? Modulo that could still break stuff for you, and the
> >> current code is adding the various -f and -w nonsense to that base before
> >> backing up and inserting -O at the next-to-last position...
> >
> > yeah, i think probably the best we can do without risking the backward
> > compatibility world of pain is to have better field auto-sizing
> > (rather than the hardcoded "7" and the Android-override "11" we have
> > atm). so at least then there's only the one special case, rather than
> > a special case on top of a special case :-)
>
> The at-the-time-ubuntu one had hardcoded widths, I made the output match
> exactly. You're the one who decided Android should have cosmetic differences
> that weren't "alias ps -o..."

i (still) have no way of knowing whether people are running it via the
shell or directly. (and, like i said, _interactive_ users aren't what
i'm worried about --- it's scripts and programs that i need to worry
about backwards compatibility for.)

> Remember when top was autodetecting units and people got upset at the jitter? At
> least top probably needs (to retain) stable spacing, and having two codepaths do
> it two different  ways...

isn't top already auto-sizing? it seems quite snug around the "10G"
for "VIRT" otherwise... oh: VIRT != VSIZE:

vsoc_x86_64:/ # ps -o VIRT
VIRT
 10G
 10G
vsoc_x86_64:/ # ps -o VSIZE
    VSZ
10799728
10874488
vsoc_x86_64:/ #

> And the way field autosizing works is to load everything into memory ahead of
> time, measure them all, and then display as a second pass, which is doable but
> not ideal for embedded systems. It does bring up "ability to sort", but there's
> no command line options for that I'm aware of because the unix way to do it is
> pipe to sort -k...

i suspect if you can't afford the memory for a _list_ of all the
running processes, your system is already well on its way to being
oom-killed :-)

> > obviously "i don't know what i don't know", but i can't actually find
> > anything internally at least that's parsing this. so maybe we could
> > try removing it from the defaults and seeing what (if anything)
> > _actually_ breaks. probably not right now though!
>
> You need your own variant of pending that's "possible API changes queued up at
> the start of a new AOSP dev cycle". (I need pending for tests. I've mostly
> gotten pending cleaned out of lib, at least locally...)

yeah, we're actually at the worst time of year for that right now.
_internal_ master detaches from the year's dessert sooner than AOSP
does (so that partners can continue to contribute publicly without
getting disappointed that their change will only be in _next_ year's
dessert), and anecdotally i'd say most people who work in AOSP by
default aren't that tied to specific releases anyway, so there's never
been the pressure for _another_ branch that would allow "work in AOSP
but for next year's dessert already" (which definitely has a non-zero
cost).

(and because it's late in the dessert cycle, that minimizes the time
available for anyone to find compatibility issues _before_ they ship.)

> >> Hmmm. I haven't implemented -x yet. (I have a whole second pass on ps to do the
> >> "ps ax" and "ps -ax" are different thing. I have plumbing! FLAGS_NODASH is set
> >> when you provided non-dash arguments...) There could be a new simpler type of
> >> output. But "there's too much complexity let's add something" seldom ends well...
> >
> > has anyone noticed yet? i feel like the BSD syntax has kind of died out?
>
> I have "ps ax" hardwired into muscle memory because of SunOS workstations in
> college. And "tar xvf" is similarly common. And I have "ar" in pending that uses
> it, and I vaguely recall one or two other uses in my notes as TODO items...

yeah, i was a `ps aux` user in the 1990s, but have switched to `ps
-elf` (or `ps -Helf` on the desktop). i realize now you mention it
that i'm probably an outlier in that i use toybox far more than most
people, so there's a natural pressure on me to drop things that don't
work there, that no-one else is feeling!

(tar, on the other hand, i've never used `-` for.)

> The BSD syntax was never _that_ widespread, but it's a lot more
> common/systematic than anything in dd. :)
>
> >> >> Rob
> >>
> >> Rob
>
> Still Rob