Hello,
after a recent update of my company Windows 10 laptop, ABCL 1.4 is landing me in an incorrect home directory. Before I contact our support I would like to investigate the problem a bit more. This is how far I got:
(user-homedir-pathname) returns #P"C:/WINDOWS/system32/config/systemprofile/"
I wrote a little Java snippet to test "user.home" public class UserHome {
public static void main(String[] args) { System.out.println(System.getProperty("user.home")); }
}
and it returns, correctly, "C:\Users\977315"
I don't know how to call System.getProperty("user.home") from ABCL.
I have multiple Java's on my laptop, and I need to doublecheck that my tests are self-consistent. But in the meantime, how do I call System.getProperty?
Thanks,
Mirko
Well. Looks like a bug in ABCL USER-HOMEDIR-PATHNAME to me.
Marco
On Jun 17, 2017, at 01:51 , Mirko Vukovic mirko.vukovic@gmail.com wrote:
Hello,
after a recent update of my company Windows 10 laptop, ABCL 1.4 is landing me in an incorrect home directory. Before I contact our support I would like to investigate the problem a bit more. This is how far I got:
(user-homedir-pathname) returns #P"C:/WINDOWS/system32/config/systemprofile/"
I wrote a little Java snippet to test "user.home" public class UserHome {
public static void main(String[] args) { System.out.println(System.getProperty("user.home")); }}
and it returns, correctly, "C:\Users\977315"
I don't know how to call System.getProperty("user.home") from ABCL.
I have multiple Java's on my laptop, and I need to doublecheck that my tests are self-consistent. But in the meantime, how do I call System.getProperty?
Thanks,
Mirko
-- Marco Antoniotti
I get the same problem with version 1.5.0.
To summarize: According to the documentation, (user-homedir-pathname) should return the value returned by System.getProperty("user.home"). That is what I am checking.
1. My test Java code call System.getProperty("user.home") to returns: "C:\Users\977315" 2. (user-homedir-pathname) returns: "C:/WINDOWS/system32/config/ systemprofile/" 1. This is the home directory of account S-1-5-18 3. I want to call System.getProperty("user.home") from ABCL, 1. (jcall "getProperty" "System" "user.home") gives error 2. (jclass "System") returns error: Class not found
I don't think it is a bug, but suspect something in my user setup (as maintained by the IT department).
I tried (user-homedir-pathname) in ABCL called from the command line. I get the same incorrect answer whether the Command window is ran as Administrator or not. So I want to examine in greater detail the environment in which ABCL is running by calling System.getProperty.
Mirko
On Sat, Jun 17, 2017 at 4:33 AM Marco Antoniotti marcoxa@cs.nyu.edu wrote:
Well. Looks like a bug in ABCL USER-HOMEDIR-PATHNAME to me.
Marco
On Jun 17, 2017, at 01:51 , Mirko Vukovic mirko.vukovic@gmail.com
wrote:
Hello,
after a recent update of my company Windows 10 laptop, ABCL 1.4 is
landing me in an incorrect home directory. Before I contact our support I would like to investigate the problem a bit more. This is how far I got:
(user-homedir-pathname) returns #P"C:/WINDOWS/system32/config/systemprofile/"
I wrote a little Java snippet to test "user.home" public class UserHome {
public static void main(String[] args) { System.out.println(System.getProperty("user.home")); }}
and it returns, correctly, "C:\Users\977315"
I don't know how to call System.getProperty("user.home") from ABCL.
I have multiple Java's on my laptop, and I need to doublecheck that my
tests are self-consistent. But in the meantime, how do I call System.getProperty?
Thanks,
Mirko
-- Marco Antoniotti
On Mon, Jun 19, 2017 at 09:33:54PM +0000, Mirko Vukovic wrote:
To summarize: According to the documentation, (user-homedir-pathname) should return the value returned by System.getProperty("user.home"). That is what I am checking.
- My test Java code call System.getProperty("user.home") to returns:
"C:\Users\977315" 2. (user-homedir-pathname) returns: "C:/WINDOWS/system32/config/ systemprofile/"
- This is the home directory of account S-1-5-18
- I want to call System.getProperty("user.home") from ABCL,
- (jcall "getProperty" "System" "user.home") gives error
- (jclass "System") returns error: Class not found
`System.getProperty` is a static method, so that should be 1. (jstatic "getProperty" "java.lang.System" "user.home") 2. and (jclass "java.lang.System"), respectively. (Or you might have to use JSS for shortcuts.)
On 6/17/17 10:12, Marco Antoniotti wrote:
Well. Looks like a bug in ABCL USER-HOMEDIR-PATHNAME to me.
ABCL's [USER-HOMEDIR-PATHNAME][1] quite clearly directly uses the value of 'user.home' Java system property.
[1]: https://gitlab.common-lisp.net/abcl/abcl/blob/master/src/org/armedbear/lisp/...
From [Section 2.2 of the manual][manual]:
The user’s home directory is determined by the value of the JVM system property 'user.home'. This value may or may not correspond to the value of the HOME system environment variable, at the discretion of the JVM implementation that ABCL finds itself hosted upon.
[manual]: http://www.abcl.org/releases/1.5.0/abcl-1.5.0.pdf
I don't see that the current behavior is a bug in ABCL, but rather the result of the JVM implementation that you are running.
If y'all see this is a bug, how would you have us "fix" it?
On Tue, Jun 20, 2017 at 3:02 AM Mark Evenson evenson@panix.com wrote:
On 6/17/17 10:12, Marco Antoniotti wrote:
Well. Looks like a bug in ABCL USER-HOMEDIR-PATHNAME to me.
This is not an ABCL bug. Thanks to Olof-Joachim's instructions:
CL-USER> (jstatic "getProperty" "java.lang.System" "user.home") "C:\WINDOWS\system32\config\systemprofile"
in accordance to the documentation. I now need to figure out why Java and ABCL think that "user.home" is "C:\WINDOWS\system32\config\systemprofile". It may be something in the computer setup that was modified last week by our IT.
PS - I never thought it was a bug, but wanted to dig a bit deeper into my JVM environment.
ABCL's [USER-HOMEDIR-PATHNAME][1] quite clearly directly uses the value of 'user.home' Java system property.
[1]:
https://gitlab.common-lisp.net/abcl/abcl/blob/master/src/org/armedbear/lisp/...
From [Section 2.2 of the manual][manual]:
The user’s home directory is determined by the value of the JVM system property 'user.home'. This value may or may not correspond to the value of the HOME system environment variable, at the discretion of the JVM implementation that ABCL finds itself hosted upon.
I don't see that the current behavior is a bug in ABCL, but rather the result of the JVM implementation that you are running.
If y'all see this is a bug, how would you have us "fix" it?
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Well. It looks like somebody’s bug nevertheless.
These are not the days of MS-DOS anymore, and I believe that W10 has a clear notion of “user home”.
Cheers — MA
On Jun 20, 2017, at 15:52 , Mirko Vukovic mirko.vukovic@gmail.com wrote:
On Tue, Jun 20, 2017 at 3:02 AM Mark Evenson evenson@panix.com wrote:
On 6/17/17 10:12, Marco Antoniotti wrote:
Well. Looks like a bug in ABCL USER-HOMEDIR-PATHNAME to me.
This is not an ABCL bug. Thanks to Olof-Joachim's instructions:
CL-USER> (jstatic "getProperty" "java.lang.System" "user.home") "C:\WINDOWS\system32\config\systemprofile"
in accordance to the documentation. I now need to figure out why Java and ABCL think that "user.home" is "C:\WINDOWS\system32\config\systemprofile". It may be something in the computer setup that was modified last week by our IT.
PS - I never thought it was a bug, but wanted to dig a bit deeper into my JVM environment.
ABCL's [USER-HOMEDIR-PATHNAME][1] quite clearly directly uses the value of 'user.home' Java system property.
From [Section 2.2 of the manual][manual]:
The user’s home directory is determined by the value of the JVM system property 'user.home'. This value may or may not correspond to the value of the HOME system environment variable, at the discretion of the JVM implementation that ABCL finds itself hosted upon.
I don't see that the current behavior is a bug in ABCL, but rather the result of the JVM implementation that you are running.
If y'all see this is a bug, how would you have us "fix" it?
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
-- Marco Antoniotti
On 6/20/17 21:35, Marco Antoniotti wrote:
Well. It looks like somebody’s bug nevertheless.
These are not the days of MS-DOS anymore, and I believe that W10 has a clear notion of “user home”.
It is a bug with the ORCL JVM, which does not properly encapsulate the notion of "user home" under Windows, probably because it has been historically revised and overloaded as (un)necessary by MSFT.
ABCL needs to support any Windows platform capable of running Java 6, not just Windows 10, so we would need code conditionalized by the Windows platform that ABCL is running on. As such, we would need a clear notion of "user home" on all existing Windows operating systems. Were someone submit such a patch, we would include it with ABCL.
The user may always specify the value of "user home" to ABCL by passing a '-Duser.home=SOMEPLACE' argument to the invoking JVM.
On Wed, Jun 21, 2017 at 1:52 AM Mark Evenson evenson@panix.com wrote:
On 6/20/17 21:35, Marco Antoniotti wrote:
Well. It looks like somebody’s bug nevertheless.
These are not the days of MS-DOS anymore, and I believe that W10 has a
clear notion of “user home”.
It is a bug with the ORCL JVM, which does not properly encapsulate the notion of "user home" under Windows, probably because it has been historically revised and overloaded as (un)necessary by MSFT.
ABCL needs to support any Windows platform capable of running Java 6, not just Windows 10, so we would need code conditionalized by the Windows platform that ABCL is running on. As such, we would need a clear notion of "user home" on all existing Windows operating systems. Were someone submit such a patch, we would include it with ABCL.
The user may always specify the value of "user home" to ABCL by passing a '-Duser.home=SOMEPLACE' argument to the invoking JVM.
In the meantime, Section 2.2 of the documentation can be updated to reflect this suggestion. Since I don't have the sources, and don't want to submit a patch, I hope the following text (derived from Mark's email) can be easily included at the end of section 2.2 (feel free to edit).
On Microsoft Windows, the notion of the user home directory is not consistent across OS releases, upgrades, and system settings. The user can specify the home directory by passing "-Duser.home=someplace" to the invoking JVM. As an example, abcl.bat file should be modified to this effect:
"C:\Windows\sysWOW64\java.exe" "-Duser.home=C:\Users..." ...
Mirko
armedbear-devel@common-lisp.net
-
Marco Antoniotti -
Mark Evenson -
Mirko Vukovic -
Olof-Joachim Frahm