It's the only command I could find that tells me I'm running an Android app on a Chromebook, something I'm going to need soon.
Changes to
the machine on Linux wouldn't affect
the LiveCode Android engine -
the Android engine uses
the Build.MODEL which it gets from
the Java Environment. Chromebooks are like Macs (as Android is) -
the OS is tied to
the hardware so one would hope that manufacturer provides a reasonable string for it
In regards to processor then Chromebooks come in both ARM and Intel flavours so its probably worth compiling using 9.5 with all Android architectures.
I'm still not quite clear what a better value for '
the machine' would be on Linux (or Windows for that matter) - both are OSes which can be installed on pretty much any 'PC' hardware. For it to have a similar meaning to iOS/Android/macOS (which is what you want in a cross-platform environment) it should be simple string describing
the actual hardware
the engine is running on... Not so much to do with hardware details but manufacturer/model etc.
Jacque's use-case is a good example - it allows her to distinguish between an Android phone/tablet and
the Android (emulation) environment on Chromebooks. In that regard it puts it in a similar category (which is its intent) to
the processor and
the platform - it allows you to make decisions at runtime based on
the environment in which your app is running.
It did occur to me last night that there is at least one Linux environment I can think of where it would be useful if '
the machine' did more than just return 'uname -m' (which looks like it is, unhelpfully, just
the processor arch of
the binary) - RaspberryPi (when we finally get a supported build).
The latter is quite a specific piece of PC-like hardware and so being able to tell if you were running on one might well be quite useful. There might be others like that too... However one issue there is you are probably looking at a huge set of cascaded switch statements to determine what 'hardware' is actually underneath, even if identifiable.
Mark Wieder's suggestion of '
the detailed ...' is quite neat - although I really don't think lscpu is
the right thing to be looking at - a
machine is much more than a cpu. However, it probably would be a way to get more detailed processor information - although morally that should probably apply to
the notion of '
the hostProcessor' rather than '
the processor' for reasons already stated.
At
the end of
the day, without explicit use-cases which people can demonstrate to be actually useful and guide what improvements could be made here then you are probably better off getting this info using shell("lscpu")... Which isn't exactly onerous is it?
P.S. I still offer
the notion of hostProcessor to solve
the OP's original problem - its 'just' a case of working out how to determine it in an atomic way on all
the platforms we support.
Possibly just 
