[Toybox] ps and top (and Android)

[Isaac Dunham]

On Sun, Apr 24, 2016 at 06:11:20PM -0500, Rob Landley wrote:
> 
> 
> On 04/24/2016 10:48 AM, enh wrote:
> > On Sat, Apr 23, 2016 at 11:53 PM, Isaac Dunham <ibid.ag at gmail.com> wrote:
> >> On Sat, Apr 23, 2016 at 09:57:12AM -0700, enh wrote:
> >> IIRC, I heard that unlink was intended to avoid the need to sanity-check
> >> and escape file names:
> >> to delete a file named '-h' or '-f', just run 'unlink -h'/'unlink -f'.
> >> Of course, GNU mis-implemented it, so it's useless if it's compatible.
> > 
> > if that was the intention, it's useless anyway, given the
> > posix-specified -- for all argument parsing.
> 
> About that:
> 
> $ echo -- hello
> -- hello
> $ /bin/echo -- hello
> -- hello
> 
> _I'm_ doing it, but the gnu tools aren't, and nobody seems to have cared.

>From the posix echo manpage:

OPTIONS
	The echo utility shall not recognize the "--" argument in the manner
	specified by Guideline 10 of the Base Definitions volume of
	POSIX.1-2008, Section 12.2, Utility Syntax Guidelines; "--" shall be
	recognized as a string operand.

> > (that they added this so late just makes it even more stupid. but
> > that's about what you'd expect from posix...)
> 
> Yeah, ln and rm are superior commands, i was just worried existing build
> scripts might use the old ones. But if so, those scripts can be fixed...
> 
> >>> what we really don't have is /usr/share/misc/pci.ids.
> >> See:
> >> http://pci-ids.ucw.cz/v2.2/pci.ids
> >> http://pciids.sourceforge.net/v2.2/pci.ids
> >> (Optionally add .gz/.bz2 for the compressed version.)
> >>
> >> Dual license, GPL2+ or 3-clause BSD.
> > 
> > what i meant is "folks would notice if i shipped an extra megabyte of
> > useless data". even the half megabyte of usb ids, which would be
> > somewhat useful, seems excessive.
> 
Unlike lspci, lsusb can get *some* text (not the same description,
but one that's useful) from the kernel.
Specifically, look in .../product rather than just .../uevent.

(Rob: you could use the second argument to dirtree_path() there,
rather than setting it to 0 and then concatenating it with a filename
in toybuf.)

> I should make it so they can be gzipped on the filesystem and it
> internally zcats them. (Not that this necessarily helps, but it's really
> easy to code once zcat is promoted: just check a second filename, xrun()
> a zcat instance on that file, and read from the output pipeline instead
> of the file. Internally lsusb/lspci would need to cache the data instead
> of lseek() and reread the file, but that's easy enough...)
> 
> But that would still mean shipping 190k of data for lsusb, which isn't
> exactly free...


The *simplest* way of making it cache (not portable! not backwards
compatible! etc...) would presumably be to call memfd_create()/
open(O_TMPFILE), xrun() zcat with that as fd 1, then operate on the
resulting fd.
This could be made to work with the current code.

The next simplest way is probably adding a magic 
 void *memcat(char **argv);
function, which would run a program with some magic such that the
output gets sent to an automatically growing buffer in memory
(essentially, malloc a temp buffer, xpopen(), copy from pipe to buffer,
if the buffer is too small, realloc() and continue till the child exits)

But that gets rather ugly if you have lots of output.

Additionally, it will require a rewrite of the device lookup code, since
that uses fgets().
But looking up 'memmem(buf, bufsiz, "\n0123", 5)' could actually
simplify it. 

Thanks,
Isaac Dunham