[Toybox] weird ps truncation

[Rob Landley]

On 01/27/2017 06:00 PM, enh wrote:
> Android has a lot of long usernames. the bluetooth code, for example,
> runs as "bluetooth", and the camera code as "cameraserver". ideally
> the USER column would grow to fit (especially when the tty is very
> wide), but right now it's kind of narrow, doesn't grow, and truncates
> from left rather than the right:

The -w flag disables this, it doesn't just ignore screen width but
disables truncation of all fields. (I.E. all strings print at their full
length.)

As for changing the default behavior: I already made the numeric fields
leak. Now it sounds like you want the string values to leak and reclaim
space, which is a less bounded problem. (The numbers aren't going to
leak _that_ much, but each string could be wider than the screen.)

Hmmm, what does ubuntu do here... "sudo useradd
thisisaverylongusername", switch to that user and "sha1sum /dev/zero"
and... Ha! Top switches from string to UID if it won't fit in the field.

And ps... darn it, how do I get non-numeric username out of this sucker
again? (ps ax, af, al don't. Ah, but "ps ax -O user" does. Why does
ubuntu have a "dbus activated colord system demon" running as its own
user? Right...)

Anyway, ps _also_ swaps UID for USER when it won't fit in the field. It
doesn't truncate, it switches output type.

(I note that we are so far beyond the behavior posix specifies for this
command the curvature of the earth would prevent us from seeing it even
with powerful telescopes. Just an FYI. No I'm not poking them about it
because Jorg.)

So what behavior do you _want_ here: swap in numbers, leak/reclaim, or
preread all preread all the entries and calculate column values like ls
does? Or just truncate from left instead of from right?

> USER       PID  PPID     VSZ    RSS WCHAN            ADDR S NAME
> ...
> raserver   609     1  115152  43496 hread_read   f4c10044 S cameraserver
> ...
> luetooth 13631     1   17808   1740 le_timeout 77105ff7e8 S wcnss_filter
> 
> similarly for LABEL; we've been lucky so far in that all the labels
> i'd seen happen to be <= 30 characters, but for the first time i've
> started to see slightly longer ones, so
> "u:r:priv_app_nxfile:s0:c512,c768", say, gets left-truncated to
> "r:priv_app_nxfile:s0:c512,c768".
> 
> my username is very short and my desktop doesn't use selinux, so
> forgive the crappy example, but afaict the tradition is to truncate
> from the right, and indicate that truncation has taken place by
> replacing the last character with '+':

I can do that too.

> ~$ ps -O user:2
>   PID USER S TTY        TIME COMMAND
> 18357 e+ S pts/23   00:00:00 -/bin/bash
> 18422 e+ R pts/23   00:00:00 ps -O user:2
> 
> ah, actually it's weirder than that...
> 
> $ adb shell ps -AZ | grep too
> u:r:bluetooth:s0               bluetoot 13320 13015 2245220  58420
> SyS_epoll_ 6fe4ab06b0 S com.android.bluetooth
> u:r:wcnss_filter:s0            bluetoot 13631     1   17808   1740
> poll_sched 77105ff7e8 S wcnss_filter
> $ adb shell -t ps -AZ | grep too
> u:r:bluetooth:s0               luetooth 13320 13015 2245220  58420
> epoll_wait 6fe4ab06b0 S com.android.bluetooth
> u:r:wcnss_filter:s0            luetooth 13631     1   17808   1740
> le_timeout 77105ff7e8 S wcnss_filter
> $
> 
> if we're writing to a tty ps calls draw_trim but if not, calls printf
> directly. so in one case we truncate from the correct side (but don't
> mark the truncation with '+') and in the other we truncate from the
> wrong side (and also don't mark the truncation).

I.E. this is a bug introduced during the switch to draw_trim. Although
the "+" for last character thing is new.

> (/me wishes Unix weren't still so ASCII; the unicode ellipsis '…'
> would be a nice improvement over '+'.)

draw_trim exists to make unicode work; user-supplied strings can be full
of it and that includes filenames, usernames, etc. I can do elipsis in
tty mode if you'd like. (Implementing's easy, figuring out the right
thing to do is hard.)

Right now it sounds like left justifying the string and doing the + is
the behavior you want, but let me know if you prefer one of the other
ones...

Rob