On Tue, Jan 31, 2017 at 12:13 AM, Rob Landley <r...@landley.net> wrote: > > > On 01/30/2017 04:20 PM, enh wrote: >> On Sat, Jan 28, 2017 at 4:16 PM, Rob Landley <r...@landley.net> wrote: >>> 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.) >> >> (yes, though it can be hard to read because the columns get shifted about.) >> >>> 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.) >> >> no, that wasn't actually what i was thinking about. i was thinking >> about sizing each column to contain its widest value. sort of more >> like how columnated ls works. > > Doable, but expensive. top is already taking 5% cpu on my netbook as > opposed to ubuntu top's 1.6%. I have a todo item to profile what it's > spending its time on and trying to streamline that a bit, but it's a > ways down the todo list. :) > >>> 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? >> >> what you've already checked in, fixing the truncation to be >> consistent, gets us back to where we were. >> >> beyond that i'm not sure... > > Me neither. > >> the "+" to show we did truncate seems helpful. > > Fiddly to implement though. The STIME field is truncated during normal > display, having that _not_ turn the last digit into + every time > requires a special case. And that's sounding like I need to audit all > the fields to see which ones need this... > > (I found a bug while I was working on that, it didn't copy the null > terminator when stripping /dev off the tty name so the display could > have trailing garbage.) > > Also I've now been staring at the code long enough I don't remember why > I only did the utf8 parsing when we a tty? We jump through hoops to find > the controlling tty, including checking /dev/tty, because ps without -a > only shows processes attached to the current terminal. But that doesn't > involve our OUTPUT being to a tty, ala "ps | cat"... So why was I making > that distinction again? Hmmm... > > It's 2 am, I should go to bed. > >> switching from USER to UID seems like a clever special case, . > > Yes, but what's expected behavior here?
no idea. i was just giving my opinion of the various choices. i personally don't really like the switch from USER to UID. that doesn't seem like it would ever be what i wanted. certainly makes scripting hard. >> doing the "+" is at least an obvious signal that something's going on >> here. i'm surprised no one's noticed before now that "bluetooth" gets >> truncated. actually, here's the list of usernames that get truncated >> on a Pixel: > ... >> 9 u0_a10000 >> >> (that last one is the start of a block of generated usernames of >> length 9, corresponding to installed apps.) >> >> maybe Android should just default to 12? > > In ps, in top, or in both? And would you still want the +? good question. but for now i haven't actually had any complaints about usernames being truncated. only SELinux label truncation has caused confusion (afaik), and that's already at 30. i think SELinux labels are the strongest motivating example for some kind of truncation marker. or column resizing like ls. some have suggested using fully-qualified app names (such as "com.android.providers.calendar" or "com.facebook.katana") instead of the generated u0_a2 style of naming, but -- even though those are theoretically more helpful -- that just seems like it's going to make it less likely that folks will see useful names. everything showing up as "com.and+" isn't much better than everything showing up as "com.andr" :-) > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net