scala-native
Scala Native seems to not set system property 'user.name'
Whilst doing cross-checks on other issues, I noticed that Scala Native 0.4.n/0.5.0-SNAPSHOT appears to not set the System property 'user.name'.
Java & ScalaJVM both set the property. I did not check Scala.js. I was surprised to see it missing in SN.
The value is readily available, both on Unix and Windows, to the code which creates the system properties map. Before I spend time implementing this, I thought I would ask:
-
It is there and I & my code just missed it?
-
If, indeed, it is not set is this by intent or the understandable and venerable "Nobody has done it yet".
-
Does anybody object to, or warn me off of, my implementing this apparently missing feature? No one has complained yet, but by the time they do, we have a disappointed user.
Thank you for comments, history, and/or suggestions.
Lee
I feel like the hill side stone farms of New England in the Spring, after the winter thaw. Pick up one stone and find three or more underneath.
I should rejoice, gives me something to do whilst waiting for CI runs and an excuse not to do what I originally set out to do.
@ekrich You have done a lot of the existing work in this area. That is the reason we have what we have.
Do you have any concern or objection to my submitting a PR setting the user property user.name
by taking the name from the activating shell environment?
I would first write a test to verify my belief that it is not currently being set.
This work would be done while I was waiting for more urgent PRs to pass CI. Which is to say "mañana".
Thank you.
user.name not set
Yes, Scala Native does not set the System Property 'user.name'.
That is described in both Java 8 & 17 in the documentation
for the Java System object as a 'standard' property
set by the JVM. There is an explicit table.
Scala Native already defines most of the "useful" properties, including
os.name, os.version, & os.arch. Several 'standard' properties
related to the JVM are not defined in SN, even as the empty string.
That is a bug, and the topic for another Issue, if I ever get the time
to create it: infinite regress.
Summary: user.name seems to be the only "useful' standard property which SN does not define.
PR closed
I closed my first attempt, WIP PR #2801 because it did not properly replicate the behavior of the Java JVM. @ekrich's review pointed out that the primary source of the user account name is used, not a translation of the USER (or USERNAME, win32, and distraction on unix; along with LOGNAME). On unix, those are set by login() when the process is created. Users can readily redefine one or more of those. Some applications use the changed value, some do not.
For future reference: Both Java 8 & 17
- Appear to query the primary source of what Java calls "User's account name".
- Ignore environment variables "USER/USERNAME/LOGNAME"
- Ignore command line "-Duser.name=DaffyDuck". That is a surprise! and special case.
- Allow a program to use
System.setProperty()to change its copy. Java strongly states that changing any System Property may lead to unwanted consequences, especially caching.
Notes:
-
the relevant call on POSIX systems is the POSIX defined "unistd.getlogin_r()"
a) That call is not currently implemented in Scala Native. Issue pending.
b) That introduces a dependency in Javalib on posixlib. We are trying to reduce/eliminate such dependencies, not introduce another one. That means the proper call is probably clib unistd.h. There currently is no such beast, so it would need to be created, probably based on the posixlib version. There goes a month, or more, of ones life dealing with "one_file/two_file" issues coordinating posixlib & clib.
-
The call on Windows appears to be:
GetUserNameA function (winbase.h). That needs to be verified.a) I am_told/have_read that Windows picks up the value for "USERNAME a.k.a %USERNAME%" from its Registry. I do not know how it handles an individual user defining a process variable with the same name. Will getenv() pickup the re-defined value?