[Toybox] Tilde expansion test on android?

[enh]

On Thu, Jan 9, 2020 at 6:20 PM Rob Landley <rob at landley.net> wrote:
>
> On 1/9/20 12:02 AM, enh wrote:
> > more likely your terminal app when it execed, but, yeah, something like that.
>
> I can just do:
>
>   HOME= sh -c "$TEST"
>
> Modulo HOME= isn't "unset home" it's "set HOME to zero length string", but I can
> write toysh to get that right... And of course bash _didn't_:
>
>   $ HOME= bash -c 'echo ~'
>
> Prints nothing. Sigh. Alright, unset it around the test so TEST_HOST passes. :P
>
> >>>> Anyway, tl;dr: ~root isn't guaranteed to expand to /root but nothing _else_ is
> >>>> likely to consistently expand to anything, and I wanna write tilde expansion
> >>>> tests. Suggestions?
> >>>
> >>> slap in another of our "wait, is this Android?" checks and skip this
> >>> test there? `[ $(id -u shell) -eq 2000 ]` would be an appropriately
> >>> uid-themed check.
> >>
> >> What _is_ a "wait, is this Android" check? (I can ANDROID_NDK in C but in a
> >> shell script, _not_ checking ? uname -s says Linux... [ -d /system/bin ] maybe?)
> >
> > we've tended to use something specific to what we're testing. stuff
> > like "if you don't have X". i think the only _literal_ OS test we have
> > is actually for macOS. but, yeah, checking for /system/bin/ isn't
> > unreasonable.
>
> It's not so much an OS test I want as a libc test. "Bionic is not checking
> /etc/passwd to get this data, it's synthesizing it internally..."
>
> Although... would [ ! -e /etc/passwd ] be a better test maybe? I vaguely recall
> sometimes there was one for some reason?

yeah, on recent releases there's an /etc/passwd (but it's often empty,
and should never contain root, though i don't think there's actually
anything to prevent an OEM from uselessly putting root in there).

> Ok, how about:
>
>   if grep -q :root: /etc/passwd 2>/dev/null
>   then
>     $ANDROID
>   fi

yeah, that should be fine on every device i'm aware of.

> > i sometimes have that on my host for testing x86-64
> > Android binaries locally, but that's also true for /data/local/tmp or
> > checking whether $ANDROID_DATA is set, or whether there's a dalvikvm
> > on your path.
>
> This is why I try to keep my dev laptop unpolluted by unnecessary installs and
> do things like the airlock step. (Aboriginal Linux used to build zlib locally
> for the mksquashfs it built in the airlock directory as part of the host tools.)
>
> (It's not science if you can't reproduce it. "Works in this guy's lab but not
> that guy's lab" is alchemy, not science. WAY too much computer science isn't.)

one of these days i'll look into this whole docker thing. my main
interest in that is actually working out how to get the github CI
working for toybox, but maybe you don't even need to know docker for
that? https://help.github.com/en/actions/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions

> > `getprop ro.build.fingerprint`, or even just checking
> > whether there's a getprop on the path?
>
> I can "which getprop", sure.
>
> > it looks like debian says /nonexistent for ~nobody, and macOS says
> > /var/empty. so that's probably good enough for non-Android? oh, but
> > ~root works on macOS too anyway --- /var/root.
>
> The problem is not knowing what to compare the string against. And yes, I'll
> need to test for macos here too so it knows to expect /var/root, but according
> to tests/du.test that's just "$(uname) == Darwin"... except the above test for
> not having an /etc/passwd with :root: in it may also trigger on MacOSX (dunno),
> so I should probably go back to the previous test.
>
> Hmmm... Do you think it would be a good idea for "uname -o" to say "Android"?
> Right now -o is a synonym for -s but it doesn't _have_ to be..

keep it as Linux and Darwin for the others, but #if __ANDROID__ output
Android? that's not a bad idea, but like you i tend to prefer the more
specific "here's what i actually need" tests rather than "tell me who
you are, and i'll guess what you're like" that something like this
would lead to. so wait until we actually need it?

> Rob