uname should return something more meaningful

[trybka]

uname(2) is currently delegated to library_syscall.js.

At present, it hard codes the following values:

    copyString('sysname', 'Emscripten');
    copyString('nodename', 'emscripten');
    copyString('release', '1.0');
    copyString('version', '#1');
    copyString('machine', 'x86-JS');

It might be nice to return something more meaningful here.

Suggestions:

• If NodeJS, provide product.versions.node
• If browser, provide navigator.userAgent
• Encode the Emscripten toolchain version here, as, in some sense, the version of the toolchain (e.g. 2.0.12) is also representative of some amount of the glue code / runtime

[kripken]

A downside to doing this is that then builds on node vs web could behave differently. Maybe that's what you want in this case, but it can make some debugging tasks harder. In general we try to avoid such differences.

I've been thinking maybe we want to add a flag to control things like this, "RAW_OS" or such, that would make more OS things like this accessible.

[sbc100]

I think returning different results from uname() seems like a relatively safe point of divergence. Most code expects variable results from this call. Do we have actual users who could benefit from accessing this information?

Also, just FYI, the emscripten version itself is already available statically at compile time.

[trybka]

We already have behavior divergence for NodeJS vs. Browser, and it might be useful to be able to easily ascertain this from uname(), but I don't feel strongly. But it's a runtime thing--encoding it as a setting makes it build-time which is likely too early.

In terms of "actual" users, our C++ Unit tests blit out a bunch of system information at the top of the logs, and Browser vs. NodeJS seems to be a notable difference in environment (akin to Linux vs. Darwin) to have at-a-glance.

[sbc100]

Sounds like there is enough of an argument for at least having an option to enable this. How about -s DUMMY_UNAME which defaults to 1.. having said that RAW_OS=1 is potentially more general, but less self-explanatory.

Perhaps we can come up with some kind of name that implies that user wants (or doesn't want) a kind of hermetic/reproducible build?

[kripken]

Thinking on this more, the suggestions in the first comment sound reasonable to me.

We do have DETERMINISTIC which we should make handle this.

[sbc100]

Sounds like great use for DETERMINISTIC yes.

[rdb]

To offer a contrasting view: I'm fairly content with sysname currently containing "Emscripten". This field tends to be a consistent way to identify the operating system for system ABI/platform distinction purposes. Python, for example, uses it to determine the platform string for binary packages, and since Emscripten mostly abstracts away the differences between the browsers (and to a large degree even node.js) and (AFAIK) a dynamically loaded wasm module is interchangeable between them, it makes sense to me to identify the platform consistently as "emscripten". If we were to change this, we would probably need to patch the Python standard library to override this setting.

I could be convinced that we need to distinguish between node.js and the browser via this field, given the differences between these environments, but I'd not at all be in favour of putting the user-agent in here. A well-behaved application should not care significantly about whether it's run in Chrome or Firefox since the "system interface" is supposed to be the same either way. In the same way, uname on a desktop does not return Ubuntu or Fedora but just Linux. There are already ways to find out the user-agent for those so inclined, using emscripten_run_script_string, or EM_JS and friends.

[kripken]

If browser, provide navigator.userAgent

In which field of uname would that go? (I was thinking machine, but based on discussion in #13440 I think I was wrong.)

[trybka]

I'm not at all bound to the idea of providing userAgent at all, was just spitballing other possibilities.

Being able to distinguish Node vs. Browser is far more valuable, as the environments are different enough to matter (at least a little bit).

I like having wasm32 or wasm64 in machine.

Per the docs for uname():

The arrays release and version shall further identify the operating system.

So I guess I was thinking of using one or both of those to provide more clarity--as the current values of 1 and #1 are pretty meaningless, IMO.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[bdenhollander]

Access to the userAgent from C++ would be useful for determining whether a meta/super key press is the Windows key and should be ignored or Cmd key on MacOS and should be treated like Ctrl (#6594). In the meantime, this is probably possible via EM_JS/EM_ASM.